[oracle_br] Re: Horário de Verão
Do ponto de vista do database Oracle, ** se ** o Sistema Operacional está com TZ corretamente setado e possui os patches de TZ adequados/necessários E SE o software RDBMS tá atualizado e rodando numa versão recente e suportada (e com os patches de timezone necessários aplicados, TODOS) e SE não há pendências de definição de datas (por exemplo, JOBs DE BANCO), aí Com Certeza não é necessário vc fazer nada, Absolutamente : o funcionamento do RDBMS em si é TOTALMENTE REFRATÁRIO à data do sistema, ele se controla por SCN, que é um 'reloginho' sequencial interno, baseado em ticks Já se TODAS as condições acima estão verdadeiras mas há Pendência programatica com data do sistema, vc VAI ter que analisar a situação : por exemplo, no caso de JOBs, se eles forem definidos via DBMS_JOB (que se controla por uma coluna DATE) é quase certo que há a possibilidade de disparo fora de hora uma hora atrasado, já se for jobs efinidos via SCHEDULER depende se a TIMEZONE usada na criação do job respeita DST(Dayligth Saving Time/horário de verão) ou não (veja a nota metalink "DBMS_SCHEDULER or DBMS_JOB And DST / Timezones Explained" (Doc ID 467722.1)... Já se for uma trigger, aí deve se analisar o código e ver qual datatype foi usado, caso tenha sido um DATE e não houver tratamento adequado é bem alta a chance de processamento incorreto/não respeito ao horário de verão... ==> A sua resposta é clara, então : a) SE vc tem 101% de certeza que as obs acima são verdadeiras, E o database reina sozinho no servidor, não há necessidade alguma de fazer NADICA de nada, MAS se vc não tem a certeza e não há Viabilidade de se fazer a Análise e confirmar, pelo seguro SIM, cabe stop e posterior restart b) só falamos acima do Database : é Óbvio que podem haver Trocentos softwares que conectam no banco e/ou rodam no servidor (exemplo, middlewares, scheduled jobs no Sistema Operacional, etc) que podem não respeitar a mudança dst/horário de verão do servidor e por si exijam stop/restart do servidor, o que IMPLICA, claro, em stop/restart do database []s Chiappa
Re: [oracle_br] Re: Horário de Verão
Conforme comentado pelo Chiappa, para corrigir o horário dos scheduler jobs, sugiro a leitura do artigo: http://www.fabioprado.net/2011/10/alteracao-de-timezone-de-scheduler-jobs.html []s Fábio Prado http://www.fabioprado.net Em 10 de outubro de 2013 11:37, J. Laurindo Chiappa escreveu: > ** > > > O database em si é ** indiferente ** ao horário do sistema, pois ele se > auto-controla através do SCN, que é um 'tick', uma "sequência > auto-incrementada em pequenos intervalos", então para o database em si > problema nenhum em se mudar o clock do sistema > PORÉM, vc tem que ter em mente duas coisas : > > a) no seu caso além do database vc está rodando um Cluster RAC, e ele (por > definição) a cada poucos segundos faz um "ping" entre os nós e a data/hora > fracionária e exata da resposta fica registrado internamente, e servirá de > comparação para causar um eventual reboot/node fencing por timeout/resposta > muito demorada : neste caso, a nota metalink "RAC: Frequently Asked > Questions" (Doc ID 220970.1) textualmente recomenda que vc baixe o > clusterware E as instâncias antes de fazer a alteração antes de fazer > alterações 'grandes' no horário : > > "Minor changes in time (in the seconds range) are harmless for Oracle RAC > and the Oracle Clusterware. If you intend on making large time changes it > is best to shutdown the instances and the entire Oracle Clusterware stack > on that node to avoid a false eviction, especially if you are using the > Oracle RAC 10g low-brownout patches, which allow really low misscount > settings. > " > > ==> Evidentemente, em adição a isso, num ambiente RAC já que é Recomendado > que vc esteja usando algum serviço externo de NTP, pode ser necessário > mudar TAMBÉM o clock no servidor NTP... Em alguns casos/configurações > ajustando o clock do NTP o client NTP até atualiza o horário local nos nós, > mas por segurança eu Ainda Diria para vc fazer um shutdown... > > b) embora o database em si seja indiferente porque usa SCN, alguns > componentes (como JOBS, por exemplo) ** usam ** o horário local , então vc > pode terminar com job não disparado : a nota metalink "DBMS_SCHEDULER or > DBMS_JOB And DST / Timezones Explained" (Doc ID 467722.1 é a referência > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, Bruno Sales > escreveu > > > > > Bom dia senhores, > > como bem sabemos, já estamos chegando no horário de verão, e com ele > chegou > > a mim algumas dúvidas: > > > > Estou utilizando um Oracle RAC 10g com 2 nós, Standard Edition, em um > > Redhat 5. > > > > Basta alterar o horário pelo Sistema Operacional que o horário do Banco > irá > > acompanhar ? E em relação às sessões das aplicações conectadas ao banco > no > > momento da virada, tambem seguirão o horário ? > > Pelo que sei, quase nao há problemas em relação à mudança para o horário > de > > verão, e o problema está mais na hora da volta, certo? > > > > Gostaria de algumas sugestões acerca do assunto, se possível. > > > > Agradeço desde já, > > > > > > > > -- > > Bruno Sales > > > > > -- Fábio Prado www.fabioprado.net "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados Oracle"
Re: [oracle_br] Re: Horário de Verão
Há algum tempo atras o Rodrigo Almeida relatou um problema ao tentar abrir um banco de teste o Oracle não conseguia fazer um Automatic Recovery da instância, pois o servidor mudou o horário devido a mudança de Data/Hora do servidor. http://www.rodrigoalmeida.net/blog/ora-600-2252-um-caso-estranho/ Nunca testei, mas se ocorreu este erro devido a mudança de Data e Hora, creio que podemos ter problemas caso precisarmos fazer uma restauração incompleta baseada em Data/Hora aplicando os archives gerados entre a mudança de horario. Alessandro Lúcio Cordeiro da Silva Analista de Sistema þ http://alecordeirosilva.blogspot.com/ De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 10 de Outubro de 2013 11:37 Assunto: [oracle_br] Re: Horário de Verão O database em si é ** indiferente ** ao horário do sistema, pois ele se auto-controla através do SCN, que é um 'tick', uma "sequência auto-incrementada em pequenos intervalos", então para o database em si problema nenhum em se mudar o clock do sistema PORÉM, vc tem que ter em mente duas coisas : a) no seu caso além do database vc está rodando um Cluster RAC, e ele (por definição) a cada poucos segundos faz um "ping" entre os nós e a data/hora fracionária e exata da resposta fica registrado internamente, e servirá de comparação para causar um eventual reboot/node fencing por timeout/resposta muito demorada : neste caso, a nota metalink "RAC: Frequently Asked Questions" (Doc ID 220970.1) textualmente recomenda que vc baixe o clusterware E as instâncias antes de fazer a alteração antes de fazer alterações 'grandes' no horário : "Minor changes in time (in the seconds range) are harmless for Oracle RAC and the Oracle Clusterware. If you intend on making large time changes it is best to shutdown the instances and the entire Oracle Clusterware stack on that node to avoid a false eviction, especially if you are using the Oracle RAC 10g low-brownout patches, which allow really low misscount settings. " ==> Evidentemente, em adição a isso, num ambiente RAC já que é Recomendado que vc esteja usando algum serviço externo de NTP, pode ser necessário mudar TAMBÉM o clock no servidor NTP... Em alguns casos/configurações ajustando o clock do NTP o client NTP até atualiza o horário local nos nós, mas por segurança eu Ainda Diria para vc fazer um shutdown... b) embora o database em si seja indiferente porque usa SCN, alguns componentes (como JOBS, por exemplo) ** usam ** o horário local , então vc pode terminar com job não disparado : a nota metalink "DBMS_SCHEDULER or DBMS_JOB And DST / Timezones Explained" (Doc ID 467722.1 é a referência []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Bruno Sales escreveu > > Bom dia senhores, > como bem sabemos, já estamos chegando no horário de verão, e com ele chegou > a mim algumas dúvidas: > > Estou utilizando um Oracle RAC 10g com 2 nós, Standard Edition, em um > Redhat 5. > > Basta alterar o horário pelo Sistema Operacional que o horário do Banco irá > acompanhar ? E em relação às sessões das aplicações conectadas ao banco no > momento da virada, tambem seguirão o horário ? > Pelo que sei, quase nao há problemas em relação à mudança para o horário de > verão, e o problema está mais na hora da volta, certo? > > Gostaria de algumas sugestões acerca do assunto, se possível. > > Agradeço desde já, > > > > -- > Bruno Sales >
[oracle_br] Re: Horário de Verão
O database em si é ** indiferente ** ao horário do sistema, pois ele se auto-controla através do SCN, que é um 'tick', uma "sequência auto-incrementada em pequenos intervalos", então para o database em si problema nenhum em se mudar o clock do sistema PORÉM, vc tem que ter em mente duas coisas : a) no seu caso além do database vc está rodando um Cluster RAC, e ele (por definição) a cada poucos segundos faz um "ping" entre os nós e a data/hora fracionária e exata da resposta fica registrado internamente, e servirá de comparação para causar um eventual reboot/node fencing por timeout/resposta muito demorada : neste caso, a nota metalink "RAC: Frequently Asked Questions" (Doc ID 220970.1) textualmente recomenda que vc baixe o clusterware E as instâncias antes de fazer a alteração antes de fazer alterações 'grandes' no horário : "Minor changes in time (in the seconds range) are harmless for Oracle RAC and the Oracle Clusterware. If you intend on making large time changes it is best to shutdown the instances and the entire Oracle Clusterware stack on that node to avoid a false eviction, especially if you are using the Oracle RAC 10g low-brownout patches, which allow really low misscount settings. " ==> Evidentemente, em adição a isso, num ambiente RAC já que é Recomendado que vc esteja usando algum serviço externo de NTP, pode ser necessário mudar TAMBÉM o clock no servidor NTP... Em alguns casos/configurações ajustando o clock do NTP o client NTP até atualiza o horário local nos nós, mas por segurança eu Ainda Diria para vc fazer um shutdown... b) embora o database em si seja indiferente porque usa SCN, alguns componentes (como JOBS, por exemplo) ** usam ** o horário local , então vc pode terminar com job não disparado : a nota metalink "DBMS_SCHEDULER or DBMS_JOB And DST / Timezones Explained" (Doc ID 467722.1 é a referência []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Bruno Sales escreveu > > Bom dia senhores, > como bem sabemos, já estamos chegando no horário de verão, e com ele chegou > a mim algumas dúvidas: > > Estou utilizando um Oracle RAC 10g com 2 nós, Standard Edition, em um > Redhat 5. > > Basta alterar o horário pelo Sistema Operacional que o horário do Banco irá > acompanhar ? E em relação às sessões das aplicações conectadas ao banco no > momento da virada, tambem seguirão o horário ? > Pelo que sei, quase nao há problemas em relação à mudança para o horário de > verão, e o problema está mais na hora da volta, certo? > > Gostaria de algumas sugestões acerca do assunto, se possível. > > Agradeço desde já, > > > > -- > Bruno Sales >
[oracle_br] Re: Horário de Verão - Oracle Enterprise - HELP
Marcus,
A única solução ficar por conta da desinstalação ?
Realmente, eu estava pensando em fazer isso, mas achei que haveria uma outra
saída.
Eu apliquei esse patch e nada e você acredita que essa nova instalação
resolverá em definitivo o problema ?
Abs
--- Em oracle_br@yahoogrupos.com.br, Marcus Vinicius escreveu
>
> Qual é a versão do seu banco de dados?
>
> Imagino que seja 10.2.0.4 ou 10.2.0.5.
>
> Nestas versões há um problema conhecido referente ao certificado raiz usado
> para garantir a segurança das comunicações através do protocolo SSL. Este
> certificado raiz expirou em 31/12/2010.
>
> A nota que cita o problema é a 1222603.1.
>
> O patch que corrige o problema é o 835062.
>
> O problema pode ser obtido através da mensagem do seu log: ERROR ssl:
> nzos_Handshake failed, ret=29024
>
>
>
>
> Abraços
>
>
> Marcus Vinicius Miguel Pedro
> Oracle ACE â
>
>
>
>
>
>
>
> On 19/10/2011, at 09:41, Jota wrote:
>
> > Alguém já passou por esse problema ?
> >
> > No enterprise eu fiz as seguintes mudanças :
> >
> > Criei uma Variavel de Ambiente no Bash_profile
> > TZ=Etc/GMT+3
> > export TZ
> >
> > Utilizei :
> > TZ=Etc/GMT+2
> >
> > Rodei o Seguinte comando: emctl resetTZ agent
> >
> > sqlplus "as sysdba"
> >
> > SQL> alter session set current_schema = SYSMAN;
> >
> > SQL> exec
> > mgmt_target.set_agent_tzrgn('hiperion.intrafeso.net:3938','Etc/GMT+2');
> >
> > Depois :
> >
> > emctl stop dbconsole
> >
> > emctl start dbconsole -- aqui dá falha e é gerado o log abaixo :
> >
> > Detalhe : Eu apliquei o patch p8350262_10205_Generic
> >
> > 2011-10-19 08:55:50 Thread-4475584 ERROR ssl: nzos_Handshake failed,
> > ret=29024
> > 2011-10-19 08:55:50 Thread-4475584 ERROR http: 6: Unable to initialize ssl
> > connection with server, aborting connection attempt
> > 2011-10-19 08:55:50 Thread-4475584 ERROR pingManager: nmepm_pingReposURL:
> > Cannot connect to https://hiperion.intrafeso.net:1158/em/upload/:
> > retStatus=-1
> > 2011-10-19 08:55:50 Thread-4475584 WARN command: Job Subsystem Timeout set
> > at 600 seconds
> > 2011-10-19 08:55:50 Thread-4475584 WARN upload: Upload manager has no
> > Failure script: disabled
> > 2011-10-19 08:55:50 Thread-4475584 WARN upload: Recovering left over xml
> > files in upload directory
> > 2011-10-19 08:55:50 Thread-22326160 ERROR ssl: nzos_Handshake failed,
> > ret=29024
> > 2011-10-19 08:55:50 Thread-22326160 ERROR http: 6: Unable to initialize ssl
> > connection with server, aborting connection attempt
> > 2011-10-19 08:55:50 Thread-22326160 ERROR command: nmejcn: failed http
> > connection to https://hiperion.intrafeso.net:1158/em/upload/: retStatus=-1
> > 2011-10-19 08:55:50 Thread-4475584 WARN upload: Recovered 50 left over xml
> > files in upload directory
> > 2011-10-19 08:55:50 Thread-4475584 WARN metadata: Metric Disk_Path does not
> > have any data columns
> > 2011-10-19 08:55:50 Thread-4475584 WARN metadata: Metric
> > osm_diskGroupPolicies does not have any data columns
> > 2011-10-19 08:55:50 Thread-4475584 WARN collector: the column name
> > DiskActivityavwait in this condition does not exist
> > 2011-10-19 08:55:50 Thread-110816144 ERROR upload: Error in uploadXMLFiles.
> > Trying again in 60.00 seconds.
> > 2011-10-19 08:55:50 Thread-62536592 ERROR ssl: nzos_Handshake failed,
> > ret=29024
> > 2011-10-19 08:55:50 Thread-62536592 ERROR http: 9: Unable to initialize ssl
> > connection with server, aborting connection attempt
> > 2011-10-19 08:55:50 Thread-62536592 ERROR pingManager: nmepm_pingReposURL:
> > Cannot connect to https://hiperion.intrafeso.net:1158/em/upload/:
> > retStatus=-1
> > 2011-10-19 08:55:50 Thread-62536592 ERROR ssl: nzos_Handshake failed,
> > ret=29024
> > 2011-10-19 08:55:50 Thread-62536592 ERROR http: 9: Unable to initialize ssl
> > connection with server, aborting connection attempt
> > 2011-10-19 08:55:50 Thread-62536592 ERROR pingManager: nmepm_pingReposURL:
> > Cannot connect to https://hiperion.intrafeso.net:1158/em/upload/:
> > retStatus=-1
> >
> > Abs
> >
> >
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
Re: [oracle_br] Re: Horário de Verão
Na verdade existe uma outra coisa que você precisa verificar no seu banco. Devido a esta alteraçao do Horario de DST (horario de verão) nos estados unidos, você precisa verificar em seus bancos se existem colunas utilizando o datatype TIMEZONE e se vc tem JVM instalado no banco. Com o select abaixo vc verifica se tem colunas com timezone select table_name, column_name, data_type from dba_tab_cols where data_type like '%WITH%TIME ZONE'; Para mais detalhes de uma olhada no metalink *Note:359145.1. * Em 22/02/07, jlchiappa <[EMAIL PROTECTED]> escreveu: > > Márcio, a nota fala sobre o JDK do Oracle Application Server, e o > colega lá diz "... Java Stored Procedures do meu banco...", portanto > suponho que na verdade ela está se referindo é a JVM nativa dentro do > banco, assim penso que a nota não se aplica > Igor, só complementando se FOR MESMO o acima : o que vc tem dentro > dum bd Oracle afaik *** não é ** uma JDK, ** não é ** um development > kit completo, é apenas uma JVM, ie, uma máquina virtual java, onde vc > pode executar códigos e mais nada, ok ??? Então quando vc > diz "acertar a hora da JDK do meu banco de dados" vou supor que é um > erro de conceito, apenas, e o que vc tem e quer é a JVM nativa e > comum do banco. > Respondendo : nunca usei funções de dete/time numa hava proc, mas > sei que o java engine é INDEPENDENTE do kernel do bd, assim VOU SUPOR > que ele provavelmente deve estar usando um clock dele mesmo - não é o > clock do SO, não é o do banco -, é um dele que ele iniciou no > startup, aí se mais à frente vc alterar clock do SO e/ou do banco, > pro JVM necas de pitibiriba... Em sendo isso mesmo, o que vc deveria > fazer é PARAR e RE-STARTAR a JVM, pois aí sim o clock dela será re- > iniciado : vc pode fazer isso baixando & subindo o banco, OU , iirc, > chamando as rotinas SERVER_SHUTDOWN e SERVER_STARTUP na package > DBMS_JAVA, certo ? Experimenta aí num servidor teste, mas afaik é > isso... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br , > "Marcio Portes" > <[EMAIL PROTECTED]> escreveu > > > > Igor, voce terá que aplicar um patch para o DST. O governo dos > Estados > > Unidos, antecipou o DST portanto diversos sistemas operacionais e > banco de > > dados (incluindo o Oracle) foram impactados com essa nova > regulamentação. > > Acredito que voce tenha que ler a nota *416288.1 *no metalink e > verificar o > > que se aplica a seu ambiente. Nessa nota, voce encontra todos os > links > > necessários para a atualização do JRE e JVM, assim como outros > impactos. > > > > On 2/22/07, Igor Laguardia <[EMAIL PROTECTED]> wrote: > > > > > > Prezados, > > > por algum motivo, de sabado para cá as Java Stored Procedures do > meu banco > > > diminuiram 1 hora, me gerando um problema muito grande. > > > Verificando o código, ví que o desenvolvedor utiliza o método > > > System.getcurrenttimeinmillis() para retornar a data atual. > Pesquisando um > > > pouco mais ví que o problema pode ser com o Horário de verão. > > > Agora a pergunta é: como faço para acertar a hora da JDK do meu > banco de > > > dados? Lembrando que a hora do banco está certa e a do sistema > operacional > > > também. > > > > > > -- > > > [ ]'s > > > Igor Laguardia > > > - > > > "Pedras no caminho?Guardo todas, um dia vou construir um castelo." > > > (Fernando Pessoa) > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > -- > > Marcio Portes > > Material Tecnico em Portugues - http://mportes.blogspot.com > > Practical Learning Oracle - > > http://mportes.blogspot.com/2006/02/practical-learning-oracle.html > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Horário de Verão
Márcio, a nota fala sobre o JDK do Oracle Application Server, e o colega lá diz "... Java Stored Procedures do meu banco...", portanto suponho que na verdade ela está se referindo é a JVM nativa dentro do banco, assim penso que a nota não se aplica Igor, só complementando se FOR MESMO o acima : o que vc tem dentro dum bd Oracle afaik *** não é ** uma JDK, ** não é ** um development kit completo, é apenas uma JVM, ie, uma máquina virtual java, onde vc pode executar códigos e mais nada, ok ??? Então quando vc diz "acertar a hora da JDK do meu banco de dados" vou supor que é um erro de conceito, apenas, e o que vc tem e quer é a JVM nativa e comum do banco. Respondendo : nunca usei funções de dete/time numa hava proc, mas sei que o java engine é INDEPENDENTE do kernel do bd, assim VOU SUPOR que ele provavelmente deve estar usando um clock dele mesmo - não é o clock do SO, não é o do banco -, é um dele que ele iniciou no startup, aí se mais à frente vc alterar clock do SO e/ou do banco, pro JVM necas de pitibiriba... Em sendo isso mesmo, o que vc deveria fazer é PARAR e RE-STARTAR a JVM, pois aí sim o clock dela será re- iniciado : vc pode fazer isso baixando & subindo o banco, OU , iirc, chamando as rotinas SERVER_SHUTDOWN e SERVER_STARTUP na package DBMS_JAVA, certo ? Experimenta aí num servidor teste, mas afaik é isso... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Marcio Portes" <[EMAIL PROTECTED]> escreveu > > Igor, voce terá que aplicar um patch para o DST. O governo dos Estados > Unidos, antecipou o DST portanto diversos sistemas operacionais e banco de > dados (incluindo o Oracle) foram impactados com essa nova regulamentação. > Acredito que voce tenha que ler a nota *416288.1 *no metalink e verificar o > que se aplica a seu ambiente. Nessa nota, voce encontra todos os links > necessários para a atualização do JRE e JVM, assim como outros impactos. > > On 2/22/07, Igor Laguardia <[EMAIL PROTECTED]> wrote: > > > > Prezados, > > por algum motivo, de sabado para cá as Java Stored Procedures do meu banco > > diminuiram 1 hora, me gerando um problema muito grande. > > Verificando o código, ví que o desenvolvedor utiliza o método > > System.getcurrenttimeinmillis() para retornar a data atual. Pesquisando um > > pouco mais ví que o problema pode ser com o Horário de verão. > > Agora a pergunta é: como faço para acertar a hora da JDK do meu banco de > > dados? Lembrando que a hora do banco está certa e a do sistema operacional > > também. > > > > -- > > [ ]'s > > Igor Laguardia > > - > > "Pedras no caminho?Guardo todas, um dia vou construir um castelo." > > (Fernando Pessoa) > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > -- > Marcio Portes > Material Tecnico em Portugues - http://mportes.blogspot.com > Practical Learning Oracle - > http://mportes.blogspot.com/2006/02/practical-learning-oracle.html > > > [As partes desta mensagem que não continham texto foram removidas] >
