ORA-00600: internal error code, arguments: [kkomiio-2], [], [], [], [], [], [], []

Hoje de manhã me deparei com o erro acima na abertura do CIGAM em determinado cliente, que o impedia de utilizar o sistema. Não encontrei referência específica alguma no Google para auxiliar na resolução do problema. Avaliei o alert.log e o arquivo.trc referente ao problema mas não consegui identificar a causa do erro. 

Gerei um log da aplicação para identificar em qual objeto do banco o erro ocorria, pois estava conseguindo acessar normalmente pelo SQLPlus. Abaixo segue trecho do log com o erro:
SELECT 1
FROM user_tables
WHERE table_name = 'TPI'
AND TEMPORARY = 'Y'

1384 ,32890 OPEN_WRITE
1384 ,32890 AUTOCOMMIT ON: FALSE
1384 ,32890 PREPARE ReadA13: SELECT 1
FROM user_tables
WHERE table_name = 'TPI'
AND TEMPORARY = 'Y'
1384 ,32890 DESCRIBE :ReadA13 INTO sqlda
1384 09:37:05,47812 OPEN :ReadA13 USING DESCRIPTOR sqlda
1384 (15 sec),47812 CALL OCIErrorGet: ORA-00600: internal error code, arguments: [kkomiio-2], [], [], [], [], [], [], []
ROLLBACK WORK

Pelo log pude ver que se tratava de um erro de acesso na "user_tables" do dicionário do Oracle. O CIGAM utiliza esta tabela para verificar se as tabelas temporárias estão criadas corretamente dentro da base de dados.

Imaginei que pudesse haver relação com problema na coleta de estatísticas da base, então apaguei todas estatísticas do dicionário e também do esquema de dados e gerei novamente. Na hora de gerar ocorreu novamente o erro. Percebi também que o servidor estava com a data 2 dias atrasada. Parei o banco, ajustei a data e subi o banco novamente, mas ainda assim não funcionou.

Suspeitei então da possibilidade de erro lógico ou físico nos discos ou partição do banco. Sendo assim verifiquei a tabela de partição do servidor que é um Debian Linux:

# /etc/fstab: static file system information.
#
#
proc /proc proc defaults 0 0
/dev/sda3 / ext3 defaults,errors=remount-ro 0 1
/dev/sda1 /boot ext3 defaults 0 2
/dev/sda6 /home ext3 defaults 0 2
/dev/sda5 /oradata xfs defaults 0 2
/dev/sda2 none swap sw 0 0
/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0
#/dev/fdc1 /media/backup auto rw,user,noauto 0 0
/dev/sde1 /media/backup ext3 rw,auto 0 0
/dev/sdb1 /bkpusers ext3 rw,auto 0 0

Pela tabela de partições pude ver que existe um partição /oradata no formato XFS. Desta forma então gerei um dump da base CIGAM, parei o banco e fiz um backup dos arquivos físicos do banco. Após isso desmontei a partição e rodei uma checagem do sistema de arquivos XFS. Acabei não gerando a saída da verificação para um arquivo de log, mas pude perceber alguns warnings em determinados momentos. A sequência de comandos foi esta:
/etc/init.d/oracle-xe stop
umount /oradata
xfs_check -v /dev/sda5
mount /oradata
/etc/init.d/oracle-xe start
Após  a checagem do disco, montei novamente a partição e subi o serviço do banco de dados. Fiz o teste de acesso ao CIGAM, que funcionou perfeitamente. 

Aparentemente era algum problema mesmo com a partição.

Comentários

Jaqueline disse…
Isso aí, muito bem Alex, parabéns! Gosto de lçer o que você escreve, de forma simples e objetiva con seguimos entender claramente.

Postagens mais visitadas deste blog

[Openfire] - Ajuste de horário no cliente Spark

Verificar uso de disco em partição ASM do Oracle 11g no Linux

[Pentaho] - Criando uma Simples transformação para apagar tabelas de um esquema no Oracle