Pular para o conteúdo

ORA-600: Erro interna no Oracle – Solução e Exemplificação

Role Separation e ORA-600 [kfdskAlloc0]

Um post rápido sobre um problema recorrente, mas que pode ajudar alguém. Como DBA você está preocupado em seguir as recomendações e melhores práticas e instala um banco de dados com “role separation”. Usuários separados, um para o Grid e um para o Oracle, mas no final das contas recebe um belo ORA-600.

No ambiente descrito aqui temos um banco de dados Oracle 11.2.0.4 instalado em um Oracle Enterprise Linux 6.5 x64 com usuários específicos para o Grid e outro para o Oracle. De qualquer forma esse erro também já ocorreu em um Exadata e em RAC, e já vi em outras versões.

Você segue o ritual e instala o Grid com sucesso, inicia a instância do ASM e instala o Oracle (com o usuário oracle). Mas ao tentar restaurar um backup ou chamar o “dbca” você recebe um “ORA-00600: internal error code, arguments: [kfdskAlloc0]”. Vou tentar exemplificar e mostrar a solução.

Como disse, temos um ambiente com “role separation”, Grid 11.2.0.4 instalado e ASM instanciado com usuário grid; Oracle 11.2.0.4 instalado com usuário oracle (mas sem instância criada). Para exemplificar tentei restaurar um backup full da produção (mas poderia ser um dbca, por exemplo). Você chama o RMAN e abre a instância com um pfile já restaurado:

RMAN> startup nomount pfile='/tmp/pfile.ora';

Oracle instance started

Total System Global Area     801701888 bytes

Fixed Size                     2257520 bytes

Variable Size                301993360 bytes

Database Buffers             494927872 bytes

Redo Buffers                   2523136 bytes

RMAN>

Depois, você continua e tenta restaurar o controlfile (com o destino sendo o ASM) e ai começam os problemas:

RMAN> run {

2>   allocate channel 'dev_0' type 'sbt_tape' parms 'ENV=(NSR_SERVER=server-networker.tjsc.jus.br,NSR_CLIENT=exadb01,NSR_DPRINTF=TRUE, NSR_DEBUG_FILE=/tmp/t1.log,NSR_DEBUG_LEVEL=2)' ;

3>   restore controlfile from 'bkp-ctf-D-dbrest-DBID-871962163-T-20131109-NB-24233.bkp';

4> }

using target database control file instead of recovery catalog

allocated channel: dev_0

channel dev_0: SID=24 device type=SBT_TAPE

channel dev_0: NMO v5.0.0.0

Starting restore at 12/11/2013 18:11:39

channel dev_0: restoring control file

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-00601: fatal error in recovery manager

RMAN-03004: fatal error during execution of command

ORA-03114: not connected to ORACLE

[oracle@cvmlx-dbrst-01 ~]$

Você olha e começa a pensar onde errou, revisa o procedimento e não acha a falha. Por fim, recorre ao “alert” da instância e descobre a origem do erro:

[oracle@cvmlx-dbrst-01 ~]$ tail -100f /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/alert_dbrest.log

...

...

MMNL started with pid=18, OS id=27009

NOTE: initiating MARK startup

starting up 1 shared server(s) ...

Starting background process MARK

Tue Nov 12 18:15:03 2013

MARK started with pid=20, OS id=27013

NOTE: MARK has subscribed

ORACLE_BASE from environment = /u01/app/oracle

Tue Nov 12 18:15:06 2013

Sweep [inc][2121]: completed

Sweep [inc2][2121]: completed

Tue Nov 12 18:16:31 2013

Errors in file /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/dbrest_rbal_27001.trc:

ORA-15183: ASMLIB initialization error [driver/agent not installed]

WARNING: FAILED to load library: /opt/oracle/extapi/64/asm/orcl/1/libasm.so

Errors in file /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/dbrest_rbal_27001.trc:

ORA-15183: ASMLIB initialization error [driver/agent not installed]

Tue Nov 12 18:16:31 2013

SUCCESS: diskgroup DATA was dismounted

ERROR: diskgroup DATA was not mounted

Errors in file /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/dbrest_rbal_27001.trc  (incident=4121):

ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []

Incident details in: /u01/app/oracle/diag/rdbms/dbrest/dbrest/incident/incdir_4121/dbrest_rbal_27001_i4121.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/dbrest_rbal_27001.trc:

ORA-00600: internal error code, arguments: [kfdskAlloc0], [], [], [], [], [], [], [], [], [], [], []

RBAL (ospid: 27001): terminating the instance due to error 488

Tue Nov 12 18:16:35 2013

System state dump requested by (instance=1, osid=27001 (RBAL)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/dbrest/dbrest/trace/dbrest_diag_26983_20131112181635.trc

Dumping diagnostic data in directory=[cdmp_20131112181635], requested by (instance=1, osid=27001 (RBAL)), summary=[abnormal instance termination].

Instance terminated by RBAL, pid = 27001

[oracle@cvmlx-dbrst-01 ~]$

Nota-se que a instância foi abortada devido ao “ORA-00600: internal error code, arguments: [kfdskAlloc0][]…”. Infelizmente para muitos o Google não é amigo (até agora) e não retorna nada relacionado (além de descobrir que tem menos de 10 links como resposta da pesquisa).

Por sorte, a solução é bem simples e já presente no MOS. Devido ao ambiente usar “role separation” o Oracle não consegue se comunicar com o Grid por estarem em grupos (de sistema operacional) diferentes. Mesmo o usuário oracle pertencendo ao mesmo grupo do usuário grid (grupo asmadmin neste caso) ele não consegue acessar o ASM.

Observe abaixo como o ASM está configurado, perceba que o usuário é o grid e o grupo é o asmadmin.

[root@cvmlx-dbrst-01 bin]# /usr/sbin/oracleasm configure

ORACLEASM_ENABLED=true

ORACLEASM_UID=grid

ORACLEASM_GID=asmadmin

ORACLEASM_SCANBOOT=true

ORACLEASM_SCANORDER=""

ORACLEASM_SCANEXCLUDE=""

ORACLEASM_USE_LOGICAL_BLOCK_SIZE="false"

[root@cvmlx-dbrst-01 bin]#

Agora olhe o binário do Oracle:

[root@cvmlx-dbrst-01 ~]# cd /u01/app/oracle/product/11.2.0.4/db_1/bin/

[root@cvmlx-dbrst-01 bin]# ls -l oracle

-rwsr-s--x 1 oracle oinstall 239626595 Nov 12 17:18 oracle

[root@cvmlx-dbrst-01 bin]#

Existem 2 soluções oficiais para o problema, a primeira mais rápida e menos traumática é mudar manualmente o grupo do binário “oracle” que está localizado em $ORACLE_HOME/bin/oracle. Essa é a solução proposta pela nota: “ORA-15183 Unable to Create Database on Server using 11.2 ASM and Grid Infrastructure (Doc ID 1054033.1)”. Seguindo esta nota a solução seria:

[root@cvmlx-dbrst-01 ~]# cd /u01/app/oracle/product/11.2.0.4/db_1/bin/

[root@cvmlx-dbrst-01 bin]# chgrp asmadmin oracle

[root@cvmlx-dbrst-01 bin]# chmod 6751 oracle

[root@cvmlx-dbrst-01 bin]# ls -l oracle

-rwsr-s--x 1 oracle asmadmin 239626595 Nov 12 17:18 oracle

[root@cvmlx-dbrst-01 bin]#

Depois de verificar a permissão atual e corrigir ela, você pode continuar a restaurar ou criar o banco com sucesso:

RMAN> run {

2>   allocate channel 'dev_0' type 'sbt_tape' parms 'ENV=(NSR_SERVER=server-networker.tjsc.jus.br,NSR_CLIENT=exadb01,NSR_DPRINTF=TRUE, NSR_DEBUG_FILE=/tmp/t1.log,NSR_DEBUG_LEVEL=2)' ;

3>   restore controlfile from 'bkp-ctf-D-dbrest-DBID-871962163-T-20131107-NB-23891.bkp';

4> }

using target database control file instead of recovery catalog

allocated channel: dev_0

channel dev_0: SID=24 device type=SBT_TAPE

channel dev_0: NMO v5.0.0.0

Starting restore at 12/11/2013 18:29:29

channel dev_0: restoring control file

channel dev_0: restore complete, elapsed time: 00:02:36

output file name=+DATA/dbrest/controlfile/current.256.831321123

Finished restore at 12/11/2013 18:32:05

released channel: dev_0

RMAN>

A solução da nota 1054033.1 é bem rápida e simples, você só tem que tomar cuidado, pois toda e qualquer atualização ou aplicação de patch vai ter quer corrigir as permissões novamente.

Existe uma segunda nota no MOS que é mais radical: “SRVCTL CHANGES THE PERMISSION AND GROUP OF ORACLE BINARY (Doc ID 1508027.1)”. A solução proposta na nota envolve a correção do conteúdo do arquivo <GI_HOME>/rdbms/lib/config.c e o relink do binário “oracle”.

Sinceramente, eu prefiro e acho bem mais simples só alterar a permissão do binário como a nota 1054033.1 sugere (bem como a solução que apresento neste post). Neste exemplo o erro foi “ORA-00600: internal error code, arguments: [kfdskAlloc0][]…”, mas pode aparecer como:

  • ORA-00600 [kfkLoadByNum03] no Oracle 10
  • ORA-00600: [kfk_load_by_idx_in_pga9] no Oracle 11.2
  • ORA-15183: ASMLIB initialization error no Oracle 11.1

Eu já vi esse mesmo erro ocorrer em um Exadata com 11.2.0.4 rodando o último PSU (de Janeiro de 2014). Como disse, a solução é simples, mas o erro pode assustar na hora, ainda mais quando você está migrando um banco de um local para outro.

Este post foi publicado em meu blog pessoal também (http://www.fernandosimon.com/blog/role-separation-e-ora-600-kfdskalloc0).

Fernando Simon

Fernando Simon

Fernando Simon, administrador de banco de dados para o Tribunal de Justiça de Santa Catarina e também como consultor na mesm área no tempo livre. Mantenho um blog (http://www.fernandosimon.com/blog) com informações para o dia a dia de um DBA e DMA Exadata.

Experiência com bancos de dados desde 2004, Oracle (9i e posteriores), SQLServer (versões desde a 2k5) e PortgreSQL (7, 8 e 9). Além de áreas relacionadas como storage, soluções de backup, virtualização e afins.

Database Machine Administrator (DMA) Exadata desde 2010, usuário e administrador (configuração, atualização e manutenção) da solução Exadata desde a versão V2. Administrador de soluções MAA (DataGuard, Rac e afins), Gerenciamento de Recursos (Database Resource Manager e IO Resource Manager - IORM) para banco de dados Oracle e Oracle Exadata.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress