Achei um ORA-600, o que faço?

Como lidar quando aparece a mensagem de ORA-600 em um banco de dados.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 patchoff para correção 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 ou problemas de disco 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 PatchSets, que é um conjunto de correções (Patchoffs) 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” sistema operacional com “tal” linguagem de programação.

Como sempre digo, ter um ORA-600na 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-600pode 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.

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,