Recuperar el ASMSPFILE con ASMPFILE generado en una instancia ASM desde una instancia ASM sana

Este caso sucedió al tratar  de parchar un nodo de un clúster en 11gR2, bajo Oracle Solaris Sparc 64, 11.1

Al no haber realizado un reinicio de seguridad de los nodoos, previo a laaplicación del parche, no supimos que ese nodo tenia problemas con un parámetro de memoria cambiado en la instancia ASM y con uno de los diskgroups

Al tratar de levantar el parche automáticamente el mismo falló con crs do not start

La solución encontrada fue la siguiente:

En el nodo no afectado

• Iniciar una sesión sqlplus sqlplus "/as sysasm"
• crear un pfile con la siguiente instrucción create pfile='/tmp/ASMpfile.ora'  from spfile;
• Verificar que el sga_max_size, no sea mayor que el memory_max_target. Si ese es el caso comentar el valor del sga_max_size en el ASMpfile.ora generado.
• Desde una sesión asmcmd ejecutar un spget, para obtener el path del ASMspfile actual
• Levanta la instancia ASM en el nodo fallido con el ASMpfile

En una ventana de mantenimiento, Para cada  nodo, uno a la vez, comenzando por los nodos con problemas

• Verificar que se disponga de una copia del archivo /tmp/ASMpfile.ora en /tmp
• Realizar un respaldo de los binarios de grid (Recomendado)
• Desde una sesión asmcmd, eliminar el registro del asmparameterfile con una instrucción similar a rm -rf +DG_OCRVOT/nombre-cluster/asmparameterfile/registry.253.787743939 , donde el valor ” +DG_OCRVOT/nombre-cluster/asmparameterfile/registry.253.787743939” es el obtenido con el spget
• Desde  sqlplus como “/as sysasm”  se  recrea el spfile create spfile='+DG_OCRVOT' from pfile='/tmp/ASMpfile.ora';

Desde root se reinicia  el crs un nodo a la vez. crsctl stop crs (verificar que baja limpiamente); crsctl start crs (verificar que sube limpiamente)

Moraleja nunca olvide realizar un reinicio de sanidad como una buena práctica