Bug 7208364: ORA-4031 (“SHARED POOL” % )”,”ASM extent pointer array”) On Stanby DataBase

Hace un tiempo que estoy siguiendo algunos errores con el dataguard que tengo en cluster, con la version 10gR2 10.2.1.0.4, y ellos ocurren en horarios aleatorios en el site donde tengo la contingencia.

Los sintomas son los siguientes:

• Caida de la instancia dataguard que esta aplicando en maxima disponibilidad, con el error “shared pool”,”unknown object”,”sga heap(1,1)”,”ASM extent pointer array”.

• El Dataguard broker levanta las instancias , pero no aplica más.

Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Fri Apr  9 05:30:45 2010
SUCCESS: diskgroup DAN_DG4 was mounted
Fri Apr  9 05:30:45 2010
RFS[30]: No standby redo logfiles of size 1024000 blocks available
RFS[30]: Waiting for thread 1 sequence 19446 archival to complete
Fri Apr  9 05:30:45 2010
SUCCESS: diskgroup DAN_DG4 was dismounted
Fri Apr  9 05:30:46 2010
RFS[30]: Archival of thread 1 sequence 19446 complete
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_asmb_30770.trc:
ORA-04031: unable to allocate 3912 bytes of shared memory
("shared pool","unknown object","sga heap(1,1)","ASM extent pointer array")
Fri Apr  9 05:30:47 2010
ASMB: terminating instance due to error 4031
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_lms1_29580.trc:
ORA-04031: unable to allocate  bytes of shared memory ("","","","")
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_lms0_29576.trc:
ORA-04031: unable to allocate  bytes of shared memory ("","","","")
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_lmon_29572.trc:
ORA-04031: unable to allocate  bytes of shared memory ("","","","")
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_lmd0_29574.trc:
ORA-04031: unable to allocate  bytes of shared memory ("","","","")
Fri Apr  9 05:30:47 2010
System state dump is made for local instance
System State dumped to trace file /u01/app/oracle/admin/DAN/bdump/DAN1_diag_29563.trc
Fri Apr  9 05:30:47 2010
Errors in file /u01/app/oracle/admin/DAN/bdump/DAN1_pmon_29561.trc:
ORA-04031: unable to allocate  bytes of shared memory ("","","","")
Fri Apr  9 05:30:47 2010
Trace dumping is performing id=[cdmp_20100409053047]
Fri Apr  9 05:30:47 2010
Shutting down instance (abort)
License high water mark = 26
Fri Apr  9 05:30:52 2010
Instance terminated by ASMB, pid = 30770
Fri Apr  9 05:30:52 2010
Instance terminated by USER, pid = 10550
Fri Apr  9 05:30:58 2010
Starting ORACLE instance (normal)

Revise la aplicación y las querys para verificar que no tuvieramos un problema con el area donde trabaja la shared pool,
pero los reportes de AWR me mostraban que todo se encontraba dentro de los parámetros normales.

Desde la placa RSA del host, reviso si llego algún alerta por bancos de memoria inactiva.

Tomo un nuevo base line del estado de la base y lo monitoreo durante varios días, y la instancia vuelve a caer por el mismo problema.

Comparo los nuevos reportes y con diferentes periodos y todo se halla dentro de los parametros normales.

En metalink encontre una nota (756095.1) donde dice que este error se produce por un bug (Bug 7208364).

Es importante destacar, que para la decisión de la aplicación del patch se deben cumplir dos variables:

• La primera, que el error debe ser el que marcamos anteriormente:

ORA-4031: unable to allocate 3912 bytes of shared memory ("shared pool","unknown object","sga heap(1,1)","ASM extent pointer array")

• La segunda, que en un ambiente de RAC NO todas las instancias deben encontrarse en modo OPEN. Al menos una debe encontarse en modo MOUNT.

De otra manera, al menos una debe ser standby.  Si no es asi, no es apropiado considerar la implementación del mismo (patch) debido a que esto solo ocurre en ambientes donde una instancias ASM esta unida , conectada a una standby.

Una vez considerado lo anterior , bajamos el patch y nos disponemos a instalarlo.

Aplicación de Patch 6981690

Detengo el broker y el recovery en caso necesario.

SQL> sho parameter broker

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1		     string	 /u06/dgbroker/dr1_DAN.dat
dg_broker_config_file2		     string	 /u07/dgbroker/dr2_DAN.dat
dg_broker_start 		     boolean	 TRUE
SQL> alter system set dg_broker_start=FALSE scope=both sid='*';

System altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

Cortamos el envio desde el sitio primario.

SQL> alter system set log_archive_dest_state_2=defer scope=both sid='*';

Detenemos la standby

[oracle@dan01lx bin]$ srvctl stop database -d DAN

Vamos al path donde guardamos el patch y lo aplicamos:

Atención ! Verficar las variables a entorno de la instancia y de ASM.
Cuando lanzamos la instalación del patch, nos mostrara en caso de tener un ambiente en RAC , todos los nodos participantes.
Podemos parar todas las instancias o hacerlo por NODO, como se ve al pie del Artículo.

Comencemos…

/u01/app/oracle/product/10.2.0/db_dan
[oracle@dan01lx 6981690]$ echo $ORACLE_SID
DAN1
[oracle@dan01lx 6981690]$ op
openjade    openssl     openvt      oprocd      oprocd.bin
[oracle@dan01lx 6981690]$ /u01/app/oracle/product/10.2.0/db_dan/OPatch/opatch apply
Invoking OPatch 10.2.0.4.2

Oracle Interim Patch Installer version 10.2.0.4.2
Copyright (c) 2007, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/10.2.0/db_dan
Central Inventory : /u01/app/oracle/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.2
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_dan/oui
Log file location : /u01/app/oracle/product/10.2.0/db_dan/cfgtoollogs/opatch/opatch2010-07-01_13-06-38PM.log

ApplySession applying interim patch '6981690' to OH '/u01/app/oracle/product/10.2.0/db_dan'

Running prerequisite checks...

OPatch detected the node list and the local node from the inventory.  OPatch will patch the local system then propagate the patch to the remote nodes.

This node is part of an Oracle Real Application Cluster.
Remote nodes: 'dan02lx' 'dan03lx' 'dan04lx'
Local node: 'dan01lx'
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/10.2.0/db_dan')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
[ .......]

Luego nos preguntara por el resto de los nodos,  donde iremos poniendo uno a uno el que escojamos (No subo los logs por que son amplios.)

Remaining nodes to be patched:
'dan02lx' 'dan03lx' 'dan04lx'
What is the next node to be patched?
dan02lx
You have selected 'dan02lx' from 'dan02lx' 'dan03lx' 'dan04lx'

The node 'dan02lx' will be patched next.

Please shutdown Oracle instances running out of this ORACLE_HOME on 'dan02lx'.
(Oracle Home = '/u01/app/oracle/product/10.2.0/db_dan')
[ .......]

Y en el ultimo nodo nos preguntara, lo mismo que los pasos anteriores.

The node 'dan02lx' has been patched.  You can restart Oracle instances on it.

The node 'dan04lx' will be patched next.

Please shutdown Oracle instances running out of this ORACLE_HOME on 'dan04lx'.
(Oracle Home = '/u01/app/oracle/product/10.2.0/db_dan')

Is the node ready for patching? [y|n]
y
User Responded with: Y
Updating nodes 'dan04lx'
Apply-related files are:
FP = "/u01/app/oracle/product/10.2.0/db_dan/.patch_storage/6981690_Dec_5_2008_05_36_03/rac/copy_files.txt"
DP = "/u01/app/oracle/product/10.2.0/db_dan/.patch_storage/6981690_Dec_5_2008_05_36_03/rac/copy_dirs.txt"
MP = "/u01/app/oracle/product/10.2.0/db_dan/.patch_storage/6981690_Dec_5_2008_05_36_03/rac/make_cmds.txt"
RC = "/u01/app/oracle/product/10.2.0/db_dan/.patch_storage/6981690_Dec_5_2008_05_36_03/rac/remote_cmds.txt"

Cuando finalice nos mostrara:

OPatch succeeded.

Levantamos la stanby , y ejecutamos los mismos pasos con el ASM.

[oracle@dan01lx bin]$ srvctl start database -d DAN -o mount

[oracle@dan01lx bin]$ srvctl status database -d DAN
Instance DAN1 is running on node dan01lx
Instance DAN2 is running on node dan02lx
Instance DAN3 is running on node dan03lx
Instance DAN4 is running on node dan04lx

Fue importante la aplicación de este patch, que si bien no fue extensa, sirve para mantener la alta disponibilidad sin puntos de down time.

Otra manera de hacerlo es trabajar con cada uno de los nodos:

NODO 1:  Bajo la instancia, Aplico en el primero, levanto.
NODO 2:  Bajo la instancia, Aplico en el segundo, levanto.
NODO 3:  Bajo la instancia, Aplico en el tercero, levanto.
NODO 4:  Bajo la instancia, Aplico en el cuarto, levanto.

Este último schema en posible y factible, y lo recomiendo en ambientes RAC.