O título deste artigo 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. Neste momento vamos refletir sobre o ORA-600, o que ele realmente significa para nós.

Quando
o encontramos 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. Através dele, pode ser encontrada a solução para seu específico erro, se existe um patch off –  uma correção para o determinado problema -, patch set, que é um conjunto de correções dos produtos, ou se há 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 épocas) 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
sebtença de morte. Tudo bem que talvez você vire algumas noites na
empresa, mas isso passa. O ORA-600 pode vir 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 entendê-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 vem o possível problema, a mensagem 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.

Ninguém
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 vem, como eu disse
acima (por SELECT, INSERT, CREATE e etc), e sempre devemos prestar atenção no primeiro argumento, pois é ele que dirá 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 mesmo, 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,