Corrupción de archivo ab_ASM1.dat
Hoy vamos por un nuevo post y que el escenario ocurre cuando trabajamos con instancias en RAC y administramos el storage de oracle bajo el modelo ASM.
Una tarde despúes de ocurrido un backup cold que se había tomado , la instancia del segundo nodo no levanto más.
Ok. Siempre guardo log’s de las operaciones y cuando reviso el evento me encuentro con esto:
RMAN> RMAN> 2> 3> + srvctl start database -d DACO PRKP-1001 : Error starting instance DACO2 on node sdat2103lx CRS-0215: Could not start resource 'ora.DACO.DACO2.inst'. + srvctl start service -d DACO + RC=0 + [[ 0 -ne 0 ]] + exit 0
El log me dice claramente que tuvo un problema al querer levantar la instancia del segundo nodo del RAC y decido levantar la instancia haciendo la misma prueba en ambos Nodos obteniendo como resultado que el problema persiste.
[oracle@sdat2101lx bin]$ srvctl start instance -d DACO -i DACO2 PRKP-1001 : Error starting instance DACO2 on node sdat2103lx CRS-0215: Could not start resource 'ora.DACO.DACO2.inst'.
Reviso el los procesos del primer nodo y veo que la instancia de base de datos y de ASM están levantadas.
[oracle@sdat2101lx bin]$ ps -ef | grep pmon oracle 10799 30253 0 11:15 pts/2 00:00:00 grep pmon oracle 19689 1 0 2010 ? 00:00:15 asm_pmon_+ASM1 oracle 20244 1 0 2010 ? 00:05:30 ora_pmon_SORN1 oracle 24016 1 0 10:52 ? 00:00:00 ora_pmon_DACO1
Bajo la instancia de base de datos con comandos de RAC ( srvctl )
[oracle@sdat2101lx bin]$ srvctl stop database -d DACO
Y al levantarla de manera manual y desde un solo el segundo nodo para ver que estaba ocurriendo, me encuentro con el error ORA-15055.
SQL> startup ORA-01078: failure in processing system parameters ORA-01565: error in identifying file '+DATA/DACO/spfileDACO.ora' ORA-17503: ksfdopn:2 Failed to open file +DATA/DACO/spfileDACO.ora ORA-15055: unable to connect to ASM instance ORA-15055: unable to connect to ASM instance
Podemos observar dos cosas de entrada:
- Que la instancia de ASM se encuentra lavantada.
- Que el spfile dentro del ASM se encuentra en el path correspondendiente.
Si la instancia esta levantada en ambos nodos como es posible que no se pueda loguear ?
Este problema suele ocurrir en las versiones de 10.2.0.3 en adelante y se debe a que el archivo ab_<ASM_SID>.dat no existe o el mismo se halla en un estado corrupto.
Una manera de darme cuenta y tener conocimiento certero si el archivo mismo causa un problema en un proceso, es usar ( en mi caso uso linux ), el comando strace o gdb.
Prueben antes con hacer un ls a un archivo por ejemplo:
jmercado@saturno:~$ strace -i ls auditoria.sql
[b8009430] execve("/bin/ls", ["ls", "auditoria.sql"], [/* 38 vars */]) = 0
[b80738fb] brk(0) = 0x89b2000
[b80741a1] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
[b80742f3] mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb805d000
[b80741a1] access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
[b8074064] open("/etc/ld.so.cache", O_RDONLY) = 3
[b807402e] fstat64(3, {st_mode=S_IFREG|0644, st_size=60501, ...}) = 0
[b80742f3] mmap2(NULL, 60501, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb804e000
[b807409d] close(3) = 0
[b80741a1] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
[b8074064] open("/lib/tls/i686/cmov/librt.so.1", O_RDONLY) = 3
[b80740e4] read(3, "\177ELF\1\1\1\3\3\1`\3100"..., 512) = 512
[b807402e] fstat64(3, {st_mode=S_IFREG|0644, st_size=34720, ...}) = 0
[b80742f3] mmap2(NULL, 33388, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb8045000
[b80742f3] mmap2(0xb804c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7) = 0xb804c000
[b807409d] close(3) = 0
[b80741a1] access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
[b8074064] open("/lib/libselinux.so.1", O_RDONLY) = 3
[b80740e4] read(3, "\177ELF\1\1\1\3\3\1pA00"..., 512) = 512
[b807402e] fstat64(3, {st_mode=S_IFREG|0644, st_size=99972, ...}) = 0
[b80742f3] mmap2(NULL, 105276, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb802b000
[b80742f3] mmap2(0xb8043000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17) = 0xb8043000
[b807409d] close(3) = 0
De esta manera podemos saber si el archivo .dat que tiene que ser leido esta causando el problema.
strace srvctl start database -d DACO
Una vez detectado el error la manera de solucionarlo es:
- Si existe, hay que renombrar el archivo y reiniciar la instancia de ASM.
- Si no existe, vamos a tener que reiniciar la instancia.
Esto recreara el archivo ab_<ASM_SID>.dat y de esta manera podremos levantar nuestra instancia de base de datos.
Entonces, lo renombro.
[oracle@sorn1 dbs]$ mv ab_+ASM2.dat ab_+ASM2.dat.ori [oracle@sorn1 dbs]$ ls -th total 44K orapw+ASM2 ab_+ASM2.dat.ori hc_+ASM2.dat.ori init+ASM2.ora -> /u01/app/oracle/admin/+ASM/pfile/init.ora orapw+ASM2.20090212 initdw.ora init.ora
Inicio la base nuevamente y observo que el archivo se crea y la instancia de base de datos se pone en modo OPEN.
También podría haber sido un error ORA-15064. Podemos ampliar mas conceptos en la nota de metalink 315214.1
