Horário de verão – Os impactos no banco de dados Oracle
by Rodrigo Almeida on jul.30, 2009, under Administração
Olá,
Nesse final de semana (14/02/2009 – DST Brazil) estamos terminando o horário de verão, que vale somente para a região Sul, Sudeste e Centro-Oeste. Com o termíno, deveremos atrasar nossos relógios em 1 hora, e isso será um grande problema para os DBAs que tem banco de dados Oracle na produção da empresa, pois apenas atrasar o horário do servidor com o banco de dados no ar (online) pode causar grandes danos.
Problemas
Ao atrasar o horário do servidor em 1 hora, e não realizar os procedimentos corretos para efetuar essa atividade, pode trazer diversos impactos ao banco de dados Oracle. E esses impactos podemos listar abaixo:
- Sobreescrita na geração dos Archived Logs;
- Problemas de comunicação com o LISTENER do Oracle Server;
- Problemas de novos registros incluídos atráves da aplicação ou processos de ETL, pois se esses registros trabalham com funções de data como SYSDATE, TIMESTAMP ou SYSTIMESTAMP, podem ser invalidadas por primarys keys e constraints de check no modelo e banco de dados;
- Para ambientes RAC (Real Application Cluster), mudar o horário pode trazer diversos problemas, desde o CRS (Cluster Registry Services), LISTENER e InterConnect, pois podem ocorrer sobreescritas na gravação dos logs e sincronização dos nós;
- Para ambientes DataGuard ou Stand-by, podem ocorrer problemas também com sobreescritas dos redo logs, onde pode causar problemas e até mesmo erros do kernel do Oracle Server gerando os ORA-600;
- Problemas nas mensagens gravadas no alert.log;
- Problemas no agendamento de JOBS no banco de dados, que seja feito por DBMS_JOB ou DBMS_SCHEDULER;
- Se ocorre a sobreescrita dos archived logs, terá problemas com o Point-in-Time-Recovery do seu banco de dados, e com isso, uma simples troca do horário pode ser uma catástrofe em seu backup e recover;
- Pode ocorrer problemas com o JVM do Oracle;
Todos os impactos citados acima, estão resumidos e que podem ser afetados de imediato, existem outros impactos que podem aparecer depois de 2 ou 3 dias e até mesmo semanas. E para não correr esse risco, existe um procedimento bem básico para os DBAs.
Procedimento
Antes de realizar a troca do horário do servidor e futuramente do banco de dados, siga os procedimentos abaixo:
- Realizar um backup full do banco de dados.
- Parar os serviços do Listener, exemplo: lsnrctl stop ou lsnrctl <nome_listener> stop;
- Parar o banco de dados, com shutdown immediate, normal ou transactional.;
- Para ambiente Windows: Depois que descer o banco de dados pelo SQL*PLUS, descer o serviço do windows, exemplo: net stop OracleService<nome_da_base>;
- Anotar o horário de STOP GERAL, para saber com exatidão o momento da parada de todos os serviços;
- Alterar o horário do servidor (Windows\Linux\Unix);
- Após a troca do horário no servidor, esperar 1 hora para subir os bancos. Exemplo, se meu STOP GERAL foi as 00:05AM (antes da troca), anoto esse valor e espero 1 hora, realizo a troca do horário e quando for 01:05AM, meu horário será atrasado para 00:05AM novamente (ajuste para o fim do horário de verão), e a partir desse horário posso subir todos os serviços novamente a partir do horário que desceu, deste modo não regresso no tempo.
- Subir todos os serviços novamento, pode ser pela ordem BANCO DE DADOS -> LISTENER -> APLICAÇÃO.
E pronto! Já estamos com nossos horários ajustados para o horário de Brasilia (Oficial Brasileiro).
Recomendação
Nunca deixem os servidores de banco de dados com o ajuste de horário de verão automático, pois a cada ano, as datas são de início e fim podem sofrer alterações e seja necessário patchs para os novos ajustes e fora que isso, pode trazer todos os problemas citados acima no banco de dados, então faça sempre manualmente.
Abraços,











fevereiro 25th, 2010 on 15:12
Olá Noberto,
Exatamente. Fica aí a dica. Valeu pela visita.
Abraços,
Rodrigo Almeida
fevereiro 19th, 2010 on 20:50
Olá Noberto,
Esse final de semana (21/02/2010) termina o horário de verão onde devemos voltar 1 hora. Então, a preocupação é com a volta do horário, que pode provocar sobreescrita dos archived logs, problemas no Enterprise Manager, problemas em JOBS e DBMS_SCHEDULER e entre outros.
Então, a todos os DBAs! Atenção nesses detalhes.
Abraços,
Rodrigo Almeida
fevereiro 18th, 2010 on 21:09
Ola Rodrigo vejo que seu artigo ja me salvou antecipadamente
domingo a meia noite muda o horário de verão e eu fiquei responsável pela mudança, nem imaginei que poderia sobscrever os archivelog do ORACLE ou mesmos dados.
dezembro 14th, 2009 on 8:17
Olá Sandro,
Referências sobre esses itens são poucos mesmos, escrevemos conforme a experiência. Para Archived Redo Log, com a alteração de horário tu pode perder o Point-in-Time de recuperação e ter problemas. Sobre o alert.log não vejo tantos problemas, pois o arquivo é criado sempre com APPEND, então é mais para facilitar a vida do DBA.
Sobre o Stand-by pode sim ter problemas, tanto trabalhando com o Stand-by Logical ou Physical, pois um trabalha com as instruções de SQL do Redo Log e outro com os archived logs. Mas seria interessante testarmos isso e fornecer um suporte melhor para essas suas dúvidas. Achei bem interessante esse ponto.
Abraços,
Rodrigo Almeida
dezembro 13th, 2009 on 21:02
Rodrigo,
digo, na questão de sobrescrita e etc.
atte.,
Sandro.
dezembro 13th, 2009 on 21:01
Rodrigo,
então, gostaria de saber de referências no manual mesmo, não encontrei algo à respeito, tampouco no Oracle Support.
atte.,
Sandro.
dezembro 10th, 2009 on 10:16
Olá Sandro,
Tudo bem! Tu gostaria de saber o que sobre esses itens, posso publicar algo a respeito deles.
Abraços,
Rodrigo Almeida
dezembro 9th, 2009 on 18:07
Almeida,
saudações, gostaria de tirar uma dúvida : não encontrei referencias sobre os itens archived log,alert.log e redo log para stand-by, poderias compartilhar ?
obrigado,
Sandro.