Horário de verão - Os impactos no banco de dados Oracle
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,

Tags: 10g, archived log, backup, banco de dados, dataguard, DBA, dbms_job, dbms_scheduler, dst, função, horário de verão, impacto, job, jvm, linux, listener, lsnrctl, modelo de dados, online, ora600, oracle, problemas, rac, recover, services, servidor, stand-by, sysdate, timestamp, unix, windows

fevereiro 15th, 2009 at 22:42
Ótimo post Rodrigo!
Realmente tem que ficar atento e fazer um bom trabalho,senão pode acarretar estes problemas que tu falou aí.
Parabéns!
Abs,
Julio Cesar
fevereiro 16th, 2009 at 18:49
Excelente, Rodrigo !
Como isso dá dor de cabeça na segunda-feira após a mudança, sempre tem alguém que não fez o procedimento correto…
fevereiro 22nd, 2009 at 15:43
É eu sei bem o que geram de impactos a não aletração desses horários malucos, passei meu final de semana trocando horários de pelo menos uns 40 servers, pouco chato isso, mas se não for realizado e sua aplicação tiver funcionalidades vinculada a horários ( Notas fiscais, emissão de Boletos, etc e tal) ficaria uma verdadeira bagunça, data de emissão não condizente com data de recebimento e por ai vai..enfim, para evitar problemas futuros, mudem os horários assim que for anunciado.
Abraço.
David
março 3rd, 2009 at 9:40
Olá Rodrigo, Parabéns pelo artigo, muito bom.
Tive um Problema com Enterprise Manager parecido com o do Eduardo mas no Oracle 10g(10.2.0.4) e resolvi da seguinte maneira:
SITUACAO DO AMBIENTE:
Verificar Timezone do Linux:
Descobrir TIme Zone do Linux /etc/sysconfig/clock
America/Sao_Paulo
—————————————————
Banco de Dados Oracle
Brazil/East
ERRO SOLICITADO PELO CLIENTE:
Erro na Pagina Home do Enterprise Manager(DB console): java.lang.Exception: IOException in sending Request
CAUSA: TIMEZONE desconfigurado no Agent do Enterprise Manager devido a troca de Horário de Verão.
SOLUCAO:
1-Criar Variavel de Ambiente no Bash_profile
TZ=Etc/GMT+3
export TZ
2-Rodar o Seguinte comando:
emctl resetTZ agent
3- conectar com o usuario SYSMAN e executar os seguinte comandos:
sqlplus /nolog
conn sysman/senha
exec mgmt_target.set_agent_tzrgn(’nome_servidor:3938′,’Etc/GMT+3′);
commit;
4-Iniciar o Enterprise Manager:
emctl stop dbconsole
emctl start dbconsole
Realmente Enterprise Manager é Xarope pra resolver.
Abraço T+
Bruno Murassaki
dezembro 9th, 2009 at 18:06
Almeida,
saudações, gostaria de tirar uma dúvida : não encontrei referencias sobre os itens sobreescrita de archived log,alert.log e redo log para stand-by, poderias compartilhar ?
obrigado,
Sandro.