Olá.

No segundo final de semana de 2009 (14/02/2009 – DST Brazil) terminamos o horário de verão, que vale somente para a região Sul, Sudeste e Centro-Oeste. Com o término, deveremos atrasar nossos relógios em 1 hora. Isso será um grande problema para os DBA´s que têm 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

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. Dentre estes impactos podemos listar:

• Sobre-escrita na geração dos Archived Logs;
• Problemas de comunicação com o LISTENER do Oracle Server;
• Problemas de novos registros incluídos através 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 sobre-escritas na gravação dos logs e sincronização dos nós;
• Para ambientes DataGuard ou Stand-by, podem ocorrer problemas também com sobre-escritas dos redo logs, que podem 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 sobre-escrita 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;
• Podem ocorrer problemas com o JVM do Oracle;

Todos os impactos citados acima estão resumidos e 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:

1. Realizar um backup full do banco de dados.
2. Parar os serviços do Listener, exemplo: lsnrctl stop ou lsnrctl <nome_listener> stop;
3. Parar o banco de dados, com shutdown immediate, normal ou transactional.;
4. 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>;
5. Anotar o horário de STOP GERAL, para saber com exatidão o momento da parada de todos os serviços;
6. Alterar o horário do servidor (Windows\Linux\Unix);
7. Após a troca do horário no servidor, esperar 1 hora para subir os bancos. Exemplo, se meu STOP GERAL foi às 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.
8. Subir todos os serviços novamente; pode ser pela ordem BANCO DE DADOS -> LISTENER -> APLICAÇÃO.

E pronto! Já estamos com nossos horários ajustados para o horário de Brasília (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 de início e fim podem sofrer alterações e talvez sejam necessários patchs para os novos ajustes; fora que isso pode trazer todos os problemas citados acima no banco de dados, então faça sempre manualmente.

Blog cadastrado no Rec6

Abraços,

\