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

Instalando gridinfrastructure NO OFA en 11gR2 Oracle Solaris Sparc64

Me he encontrado con el inconveniente de instalar el GRIDINFRASTRUCTURE bajo estándart NO OFA o NON OFA.

Como estamos acostumbrados a instalar bajo el estándar OFA /u01 a /u09. Típicamente /u01 para clusterware y RAC, y /u02 para productos de middleware, nos parece fuera de contexto no seguir estas guías

La situación era la siguiente:
Instalar un RAC en 2 nodos con GRID_HOME y ORACLE_HOME locales (NO SHARE) en cada nodo.

Los FS se denominan
/oracle/app/grid para los binarios de clusterware grid
/oracle/app/oracle para los binarios del RDBMS

El GRID_HOME sugerido por el instalador es /oracle/app/11.2.0/grid, con el GRID_BASE /oracle/app/grid, pero esto  no cumple con los estándares indicados para la instalación

El inconveniente era que de momento no sabiamos como hacer para  crear correctamente el GRID_HOME /oracle/app/grid/product/11.2.0.4 sin que se produjera el error

[INS-32026] The Software Location specified should not be under Oracle base location.


Por lo que la solución más sencilla consistió en crear un subdirectorio llamado oracle_base, en ambos nodos con el usuario grid bajo el Filesystem /oracle/app/grid y cambiar el $GRID_BASE a 

/oracle/app/grid/oracle_base, lo que permite crear el GRID_HOME correctamente como /oracle/app/grid/product/11.2.0.4