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á,

O título desse post já diz muita coisa, “Achei um ORA-600, o que faço?”. Muitos gostariam de ter o botão EJECT na cadeira, outros de ser ninjas e jogar o pó para desaparecer e alguns gostariam de ser o novo David Blaine. Na verdade, esse número “cabalístico” de erro pode ser o início de uma longa jornada.

O RDBMS (Relational Database Management System) Oracle possui dois códigos de erros que assustam qualquer DBA, o bendito ORA-600 e ORA-7445, mas nesse momento, vamos refletir sobre o ORA-600, o que ele realmente significa para nós.

Quando nós encontramos ele no alert.log ou diretamente pelo Oracle Server (via SQL*PLUS ou qualquer outra aplicação), significa que temos um problema na aceitação do comando no kernel do RDBMS ou temos uma inconsistência em um determinado processo, que geralmente, pode estar associado a um BUG, **MAS**, nem sempre é um BUG, por isso que temos que ter muita calma nessa hora. O Metalink disponibiliza uma ferramenta de pesquisa para esse específico erro, o chamado ORA-600 Lookup tool. Atráves dele, pode ser encontrado a solução para seu específico erro, se existe um patch off  uma correção para o específico problema, patch set que é um conjunto de correções dos produtos ou ou se existe um simples workarround “gambiarra” para realizar.

O ORA-600 pode ser um problema causado por diversos fatores, como:

• Falta de recurso de hardware

A falta de recursos de memória, problemas de disco ou problemas no funcionamento do hardware podem auxiliar seu aparecimento.

• Configuração do Sistema Operacional

Uma má instalação e falta de patchs no sistema operacional pode causar o ORA-600, e quando digo má instalação, gosto de me referir aquela instalação, NEXT-NEXT-FINISH.

• Falta de atualização do banco de dados

Podem perceber que a Oracle, quando lança um produto, possui diversos Patch sets, que é um conjunto de correções (Patch offs) que é detectado pelo suporte da Oracle em acompanhamento de seus clientes. A falta de atualização só aumenta a sua chance de ter um amigo ORA-600.

• Utilização de News Features

Sempre que é lançada uma versão nova de banco de dados, com por exemplo, versão, 8.1.0, 9.1.0, 10.1.0 ou 11.1.0, (lógico, em suas respectivas epócas) e na sua aplicação começa a utilizar as features da versão (novos recursos de desenvolvimento ou banco de dados), **COM CERTEZA**, encontrará um ORA-600 em algum momento de sua humilde vida. Isso é porque o Kernel do RDBMS ainda não está “amadurecido” para executar “tal” tarefa, sobre “tal” hardware, com “tal” sistema operacional com “tal” linguagem de programação.

Como sempre digo, ter um ORA-600 na base de dados nem sempre é uma questão de desespero ou assinar a setença de morte, tudo bem que talvez possa virar algumas noites na empresa, mas isso passa. O ORA-600 pode vim a qualquer momento, porque ele é resultante de diversos fatores como dito acima e **SIM**, para alguns tipos de ORA-600, podem ser resolvidos rapidamente.

Toda vez que se tem um ORA-600, é gerado um arquivo de trace no servidor, no diretório USER_DUMP_DEST ou BACKGROUND_DUMP_DEST(depende qual será o processo afetado). Nesse arquivo de trace, para quem é mais experiente, poderá encontrar as raízes dos problemas. Pode ser um “LAZARENTO” de uma instrução de SELECT que faz join com uma INLINE VIEW, que também faz um hash join com uma Materialized view e tem uma view com dblink que força o aparecimento do ORA-600, ou como pode ser um simples INSERT em tabelas IOT e assim vai, só com bastante analise iremos saber as causas. Mas onde quero chegar com isso?

Quando se tem o erro ORA-600 em mãos, devemos tentar entende-lo, como mostra um exemplo de mensagem abaixo:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

ou

ORA-00600: internal error code, arguments: [12209], [498], [], [], [], [], [], []

Podemos ter uma idéia de onde vêm o possível problema, a menssagem de erro é sempre composta por ORA-600 [argumento1] [argumento2] até o [argumento8]. Se estudarem a arquitetura interna do Oracle, o kernel é composto por diversas travas que fazem o controle, acesso e utilização dos dados.

Nínguem sabe dizer com 100% de certeza, se o kernel do Oracle é puramente escrito na linguagem C, mas dizem que possui algumas coisas em Java para os releases superiores ao 9i. Pois bem, isso não interessa até o momento, eu quero apenas exemplificar como o kernel trabalha.

Analisando o trace gerado, podemos ter a idéia de onde ele vêm, como eu disse acima (por SELECT, INSERT, CREATE e etc), e sempre devemos prestar a atenção no primeiro argumento, pois ele que irá dizer em qual momento ou trava ocorreu o problema.

No primeiro erro mencionado, nosso primeiro argumento foi o kcbz_check_objd_typ_3, que internamente para o Oracle a trava KCBZ quer dizer Kernel Cache Buffer, então já podemos ir mais profundamente e pensar que ocorreu um erro no tratamento da informação durante sua passagem pelo SGA.

No segundo erro, como não existe nenhuma trava mencionada no primeiro argumento, e não envolve travas do kernel, pode ser algum problema apenas como manipulação dos dados ou quebra de integridade interna, e por isso, dá uma esperança que pode ser um ORA-600 com resolução rápida.

Ambos os erros, podem estar associados a um BUG da versão ou apenas uma má interpretação do banco de dados, isso, apenas olhando o erro e o trace não iremos conseguir garantir nada. É apenas um exemplo e modo de como podemos se comportar com um ORA-600 no banco de dados.

LEMBRETE

Sempre, **MAS**, sempre que tiver um ORA-600 em sua base de dados, acione de imediato o suporte da Oracle para analisar profundamente os motivos do aparecimento do problema e realizar uma investigação sobre seu ambiente, como mencionado, os fatores podem ser diversos e também pode ser ou não um real BUG da sua versão.

Estou apenas dizendo uma experiência que tenho no dia-a-dia e não me responsabilizo pelos seus atos. Espero que tenham gostado desse assunto e que possa entender melhor o motivo do nosso velho amigo ORA-600.

Abraços,