10.2.0.4.4 Patch Set Update on RAC

Applying the 10.2.0.4.1 Patch Set Update (PSU)

Ante todo los saludos desde Argentina a todos mis compatriotas IberoAmericanos & Anglos.

Gracias a todos por lograr llegar a las 60.000 visitas este trimestre en curso.

Tambien a la Comunidad Oracle Hispana de la cual estoy orgulloso de ser miembro y donde he cosechado buenos amigos.

Estuve bastante ocupado con migraciones de versiones, instalaciones de cluster, aplicaciones de parches, etc y con ello anduve corto de tiempo.
Pero entre todos los articulos con material que tengo para escribir y publicar me decidi comenzar con este.
EL motivo del articulo es dar a conocer como implemente un PSU en un RAC con su Standby correspondiente tambien montada sobre un RAC.

En el proximo articulo estare explicando los motivos de la implementacion del mismo, ya que fue un caso muy particular.

Debio ser instalado como consecuencia de la aparicion de bugs, despues de haber aplicado el parche 7442260.

Espero que les sea de utilidad.

Problema:
========

Cuando instalamos el patch 7442260, nuestra rdbms comenzo arrojar varios errores ORA-07445 y provoco en varias oportunidades hangs en el cluster.

ORA-07445: exception encountered: core dump [ksuklms()+527] [SIGSEGV]" 
appears in all nodes in production after that we applied the patch 7442260

Luego de investigacion y trabajo en conjunto , desde Oracle Support nos recomendaron realizar la instalacion del 9352164: DATABASE PSU 10.2.0.4.4 (INCLUDES CPUAPR2010)

Y de ahi es donde surge este articulo que cumple como objetivo escencial instalar un PSU de oracle en un ambiente interesante.

Grid Infraestructure (clusterware 11.2.0.2) Oracle Database 10.2.0.4 Dataguard Activo. 

Vamos entonces a lo tecnico.

Comenzamos trabajos Trabajos Tecnicos

DESACTIVAMOS EL ENVIO EN LA PRIMARIA

SQL> alter system archive log current;

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

DESACTIVAMOS EL BROKER EN LA PRIMARIA

SQL> alter system set dg_broker_start=false scope=both sid='*';

System altered.

Comenzamos trabajos desde el Sitio Secundario.

Comencemos estonces con desactivar la aplicacion de los logs que antes llegaban a nuestro sitio.

DESACTIVAMOS EL BROKER EN LA SECUNDARIA

SQL> alter system set dg_broker_start=false scope=both sid='*';

System altered.

Bajamos  la base  STANDBY

srvctl stop database -d PENNY

Bajamos los listener en todos los nodos.

srvctl stop listener -n sdat0001lx -l PENNY_SDAT0001LX
srvctl stop listener -n sdat0002lx -l PENNY_SDAT0002LX
srvctl stop listener -n sdat0003lx -l PENNY_SDAT0103LX
srvctl stop listener -n sdat0004lx -l PENNY_SDAT0104LX

Aplicamos el parche de los binarios en la standby

1) Nos vamos al path donde se encuentra nuestro parche y lo descomprimimos.

cd /u01/app/oracle/patches/

Luego vamos hacer un control por que debemos veriicar que no tenemos conflictos con otros parches.

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9352164

Ingresamos donde se encuentra nuestro patch.

cd 9352164

Aplicamos el parche.

$ORACLE_HOME/OPatch/opatch apply

La aplicacion del parche nos ira preguntando si estamos listo & que nodo es el proximo a ser patcheado.

Esto lo hace por que tiene la opcion de rolling upgrade donde lo podemos hacer nodo a nodo ordenadamente sin bajar los servicios de bases de datos & al final se pone una ventana donde podemos ejecutar la seccion de sql. En nuestro caso se pidio una ventana de mantenieminto que fue concedida entonces lo aplicamos de un solo tiron.

Una vez aplicado el parche de binarios procedemos con el usuario root & en cada uno de los nodos miembros a ejecutar :

# export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_PENNY

Vamos al sitio donde se encuentra el parche.

cd /u01/app/oracle/patches/9352164

Ejecutamos en cada uno de los nodos.

bash -x psu_root.sh

Ahora podemos montar nuestro sitio STANDBY.

srvctl start database -d PENNY -o mount

Levantamos los listener.

srvctl start listener -n sdat0001lx -l PENNY_SDAT0001LX
srvctl start listener -n sdat0002lx -l PENNY_SDAT0002LX 
srvctl start listener -n sdat0003lx -l PENNY_SDAT0103LX 
srvctl start listener -n sdat0004lx -l PENNY_SDAT0104LX

Ahora con la aplicacion del parche en los binarios podemos proceder a la aplicacion del parche en el sitio PRIMARIO.

Comenzamos con trabajos en el sitio Primario

Comenzaremos con la aplicacion del parche de los binarios & luego procedemos al modo sql.

Bajamos la base & los listener

Paramos la base primaria para comenzar con la aplicacion del parche en los binarios de la base.

srvctl stop database -d RAYEN

Paramos los listener.

srvctl stop listener -n sdat2001lx -l RAYEN_SDAT3100LX 
srvctl stop listener -n sdat2002lx -l RAYEN_SDAT3102LX 
srvctl stop listener -n sdat2003lx -l RAYEN_SDAT3104LX 

Vamos a donde tenemos el patch desplegado

cd /u01/app/oracle/stage/patches/

Comprobamos que no haya incompatibilidades con otros parches

$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9352164

APLICAMOS PATCH

cd 9352164

Aplicacion del parche.

$ORACLE_HOME/OPatch/opatch apply 

You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: y

OPatch succeeded.
[oracle@sdat2001lx 9352164]$

Como root ejecutamos en cada nodo.

# export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_RAYEN
# cd /u01/app/oracle/stage/patches/9352164
# bash -x psu_root.sh

Vamos a correr en la base la creacion de los scripts como usuario oracle.

 cd $ORACLE_HOME/rdbms/admin sqlplus / as sysdba STARTUP @catbundle.sql psu apply @utlrp.sql QUIT 

Revisamos en el mismo path que haya creado los scripts de la vuelta atras.

ls catbundle*

Nos desplegara unos archivos similares a estos

catbundle_PSU_RAYEN_APPLY.sql 
catbundle_PSU_RAYEN_ROLLBACK.sql  
catbundle.sql

Hacemos un control de compilacion de Vistas.

 sqlplus / as sysdba SQL> SELECT * FROM registry$history where ID = '6452863'; no rows selected

Ahora ejecutamos el UPGRADE del parche en el modo sql, para que en la base se cree los objetos o se recompilen apuntando a los nuevos binarios.

 cd $ORACLE_HOME/cpu/view_recompile
 sqlplus / as sysdba 
SQL> @recompile_precheck_jan2008cpu.sql 
SQL> shutdown immediate 
SQL> STARTUP NOMOUNT 
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile SID='*'; 
SQL> shutdown immediate 
SQL> STARTUP UPGRADE 
SQL> @view_recompile_jan2008cpu.sql

Aca les dejamos una referencia del resultado, ya que este es un paso demora un poco y genera bastante log.

 No. of Invalid Objects is :28 
Please refer to README.html to for instructions on validating these objects PL/SQL procedure successfully completed. 
Logfile for the current viewrecomp.sql session is : vcomp_OT2T1N_09Apr2012_18_06_06.log

Compilamos las vistas descompiladas.

SQL> @?/rdbms/admin/utlrp.sql

Modifcamos el parametro de cluster.

ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=spfile sid='*'; 
shutdown immediate startup 

Ahora podemos realizar el cehqueo en el sitio PRIMARIO

 SET LINE 150 
SET PAGESIZE 100 
col version format a20 
COL ACTION_TIME FORMAT a30
col ACTION format a8 
SELECT ACTION_TIME, ACTION, NAMESPACE, VERSION , BUNDLE_SERIES, ID FROM REGISTRY$HISTORY 
ACTION_TIME ACTION NAMESPACE VERSION BUNDLE_SERIES ID
------------------------------ -------- ------------------------------ -------------------- ------------------------------ ----------
29-NOV-08 03.44.13.280549 PM UPGRADE SERVER 10.2.0.4.0
09-APR-12 05.37.26.024426 PM APPLY SERVER 10.2.0.4 PSU 4
09-APR-12 06.08.35.472847 PM CPU 6452863

SQL>

Podemos verificar que cambios ocurrieron.

$ORACLE_HOME/OPatch/opatch lsinventory

Levantar listener en EL SITIO PRIMARIO

srvctl start listener -n sdat2001lx -l RAYEN_SDAT3100LX 
srvctl start listener -n sdat2002lx -l RAYEN_SDAT3102LX 
srvctl start listener -n sdat2003lx -l RAYEN_SDAT3104LX

Levantar con srvctl EL SITIO PRIMARIO

srvctl start database -d RAYEN -o open

Levantar con srvctl LOS SERVICIOS SITIO PRIMARIO

srvctl start service -d RAYEN 
Habilitamos el envio de LOGS al sitio SECUNDARIO
SQL> alter system set log_archive_dest_state_2=enable scope=both sid='*';

System altered.

En la STANDBY habilitamos el Manage Recovery MANUAL

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Database altered.

Verificamos la aplicacion de logs

 select NAME, THREAD#, SEQUENCE#, APPLIED, registrar from v$archived_log where name like '+O%' order by sequence#; 

Cortamos el recovery

SQL> alter database recover managed standby database cancel;Database altered.

HABILITAMOS EL BROKER EN LA PRIMARIA

SQL> alter system set dg_broker_start=true scope=both sid='*';System altered.

HABILITAMOS EL BROKER EN LA SECUNDARIA

SQL> alter system set dg_broker_start=true scope=both sid='*';System altered.

Por Ultimo realizamos el chequeo en el sitio SECUNDARIO, ya que con el envio de LOGS debio impactar los cambios en los objetos de la base.

SET LINE 150 
SET PAGESIZE 100
col version format a20
COL ACTION_TIME FORMAT a30 
col ACTION format a8 
SELECT ACTION_TIME, ACTION, NAMESPACE, VERSION , BUNDLE_SERIES, ID FROM REGISTRY$HISTORY 
ACTION_TIME ACTION NAMESPACE VERSION BUNDLE_SERIES ID 
------------------------------ -------- ------------------------------ -------------------- ------------------------------ ----------
29-NOV-08 03.44.13.280549 PM UPGRADE SERVER 10.2.0.4.0
09-APR-12 05.37.26.024426 PM APPLY SERVER 10.2.0.4 PSU 4
09-APR-12 06.08.35.472847 PM CPU 6452863
SQL>

Espero les haya sido de Utilidad, Un gran Abrazo !