BLOG RODRIGO ALMEIDA

Olá,

Algumas semanas atrás, tive um problema com um banco de dados que eu tinha acabado de criar, um caso muito estranho, tudo funcionava perfeitamente e no outro dia, o banco não iniciava por problemas de ORA-600, poderia ser um caso de pesquisar no Metalink para resolver o problema, mas por curiosidade, resolvi analisar de onde pelo menos esse erro acontecia ou tentar saber o que poderia ter acontecido com meu hardware. O erro exato do ORA-600, está abaixo:

ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []

Como eu estava tentando entender o problema, fui pesquisar sobre o primeiro argumento do ORA-600, o argumento 2252, onde ele se referia a categoria de base 2000, que é referente a funcionalidade do Cache Layer, porém, como o argumento exato é 2252, estava relacionada diretamente a funcionalidade de RCV (Recovery), e o valor 252 é para diversas funcionalidades voltadas ao SCN.

O erro sempre acontecia no momento que eu tentava abrir o banco de dados, executando o ALTER DATABASE OPEN, fora isso, meu banco de dados conseguia montar sem problemas! Então, começei a levantar algumas informações sobre o hardware, como por exemplo:

• O servidor já tinha 5 anos de uso.
• Fabricante DELL.
• O sistema operacional, tinha acabado de ser instalado, estava sobre a Plataforma Linux Red Hat EL AS 4 em 32-Bits, observando os logs do SO, também não encontrava problemas.
• O banco de dados, recém instalado e configurado.

O problema estava misterioso, quando resolvi analisar cuidadosamente o erro no alert.log, e me deparei com alvo assim:

Wed Jan  9 23:45:57 2002
Successful mount of redo thread 1, with mount id 1181935665
Wed Jan  9 23:45:57 2002
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Wed Jan  9 23:46:07 2002
alter database open
Wed Jan  9 23:46:07 2002
Errors in file /u01/app/oracle/admin/esdp/udump/esdp_ora_31553.trc:
ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []
Wed Jan  9 23:46:08 2002
ORA-600 signalled during: alter database open...

Lembra que disse que eu tive problemas há algumas semanas atrás, isso é no ano de 2008, todos os registros de alerta estavam com a data de 2002!! Resolvi apenas executar um DATE no Linux diretamente para ver a data, quando me deparei com o ano de 2002 também!

O argumento que o ORA-600 estava apontando estava correto, na trava certa, pois quando criei o banco de dados e realizei o import de várias dados atráves do datapump, meus primeiros archives e entradas de REDO, estava com a data de 2008, quando o servidor perdeu essa data e regrediu, é correto o Oracle Server afirmar que não consegue fazer um Automatic Recovery da instância, quando realiza a abertura do banco, pois como um banco de dados pode começar os primeiros archives na data de 2008 e depois pedir uma recuperação de 2002!!! Meio complicado.

Só para compreender melhor, olhe como estava a minha área de db_recovery:

[oracle@pelspos13 archivelog]$ ls -R
.:
2002_01_05  2008_07_31  2008_08_01  2008_08_04  2008_08_11
./2002_01_05:
o1_mf_1_1_y3dz9wbt_.arc   o1_mf_1_81_y3dx0npt_.arc  o1_mf_1_83_y3dx2ftp_.arc
o1_mf_1_80_y3dx3gmy_.arc  o1_mf_1_82_y3dx1496_.arc
./2008_07_31:
./2008_08_01:
./2008_08_04:
./2008_08_11:
o1_mf_1_82_4b1r5349_.arc
[oracle@pelspos13 archivelog]$

Sendo que os archives da data de 05/01/2002, seria “teoricamente” os archives mais recentes!!!

Agora, a causa disso tudo, simples! A bateria da placa mãe do servidor, como essa bateria já deveria estar com problemas, quando o servidor era reiniciado, ele voltava para a data de fabricação da placa, e com isso, todo o sistema operacional também voltava, e consequentemente, meu banco de dados.

Como trabalhava no modo ARCHIVELOG, ao abrir o banco de dados, apresentava esse erro bonito. Se for analisar, é um erro “besta”, que poderia ser resolvido rapidamente, mas, um simples erro, muitas vezes é díficil de se perceber.

Abraços,

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:

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 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.
8. 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,