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.