Briefing sobre um erro com ORA-600 [2252] em ambiente Linux Red Hat 32-Bits.
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
