Oracle 11g

Si estamos en la version 11g deberemos de hacerlo consultando la tabla del diccionario sys.registry$history

SET LINESIZE 180 PAGESIZE 90 COLUMN FECHA FORMAT A18 COLUMN action FORMAT A20 COLUMN version FORMAT A10 COLUMN comments FORMAT A30 COLUMN bundle_series FORMAT A10 SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI') AS FECHA, action, namespace, version, comments, bundle_series FROM sys.registry$history ORDER by action_time;

Lo que nos devolvera algo similar a :

FECHA ACTION NAMESPACE VERSION COMMENTS BUNDLE_SER ------------------ -------------------- -------------------- ---------- ------------------------------ ---------- 07-JAN-2017 15:21 APPLY SERVER 11.2.0.3 PSU 11.2.0.3.15 PSU 01-DEC-2017 18:59 UPGRADE SERVER 11.2.0.4.0 Upgraded from 11.2.0.3.0 01-DEC-2017 19:00 APPLY SERVER 11.2.0.4 PSU 11.2.0.4.171017 PSU

Preguntando a DBA_REGISTRY_SQLPATCH

La consulta sera muy similar a la anterior, pero en ved de preguntar a el dicionario sys.registry$history, lo haremos a la tabla DBA_REGISTRY_SQLPATCH

SET LINESIZE 180 PAGESIZE 90 COLUMN FECHA FORMAT A20 COLUMN action FORMAT A10 COLUMN status FORMAT A20 COLUMN description FORMAT A90 COLUMN version FORMAT A10 COLUMN bundle_series FORMAT A10 SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI:SS') AS action_time, action, status, description, version, patch_id, bundle_series FROM sys.dba_registry_sqlpatch ORDER by action_time;

Lo que nos devolvera algo similar a

ACTION_TIME ACTION STATUS DESCRIPTION VERSION PATCH_ID BUNDLE_SER -------------------- ---------- ---------- ---------------------------------------- ---------- ---------- ---------- 07-MAR-2018 21:37:51 APPLY SUCCESS Database Patch Set Update : 12.1.0.2.4 12.1.0.2 20831110 PSU (20831110)

Mediante el package dbms_qopatch

En la version 12c tenemos el nuevo datapatch en los parcheados, la informacion de los parches de la base de datos esta tambien accesible con el package dbms_qopatch.
Esto ya lo vimos en la entrada Obtener los parches instalados en la base de datos CDB que venia a decir :

set serverout on exec dbms_qopatch.get_sqlpatch_status;

Lo que nos devuelve

Patch Id : 25171037 Action : APPLY Action Time : 14-JUN-2017 23:09:33 Description : DATABASE PATCH SET UPDATE 12.1.0.2.170418 Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/25171037/21099266/25171037_apply_SID_2017Jun14_23_09_20.log Status : SUCCESS PL/SQL procedure successfully completed.

Sobre el uso de dbms_qopatch tenemos la URL hay una URL Como saber si un parche esta aplicado en la BBDD que tiene consultas muy utiles para obtener informacion de la base de datos (inventario,paches…)

Esta informacion ha sido obtenido en su totalidad de las URLS:

Hoy vamos a ver unas nociones rápidas sobre el parchado en un RAC
Parchear el RAC es diferente al parcheado de un sibgle node, si Opatch detecta un cluster preguntará al OUI el nombre del nodo local y el listado de nodos.
Además de esto, antes de instalar un parche hay que parar todoas las aplicaciones que corren en ese directorio de software deben de pararse.

Exsisten 3 métodos de parcheado de un RAC

All Node Patching
Rolling Patching
Minimum Dowtime

Para llevar a cabo el parchado seguiremos los siguientes pasos:
1. Parar el grid y todo lo que dependa de el en el nodo ( incluido ASM de single instances)
2. Desbloquear el GRID_HOME, como root ejecutaremos
cd $GRID_HOME/crs/install perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid
Al ejecutar el rootcrs.pl con el flag -unlock desbloqueamos el GRID_HOME con lo que ya puede modificarse
3.Con el usuario del grid p parcheamos con el método que elijamos ( ver 3 métodos)
4. Como root de nuevo,volvemos a bloquear los binarios del grid con
cd $GRID_HOME/crs/install perl rootcrs.pl -patch
Al ejecutar el rootcrs.pl con el flag -patch bloqueamos el GRID_HOME y se rearranca el Oracle Clusterware stack

Métodos de parcheado

Vamos a describir cada uno de los tres métodos de parchado y las diferencias entre ellos

All Node Patching

Este método consiste en parar todos los recursos de todos los nodos y se instalan a la vez. una vez están todos parcheados arrancamos de nuevo.
Esté método es el que se usa típicamente para los parches críticos y es el que tiene el máximum downtime.
Opatch usa este método cuando el parche no puede aplicarse en “ rolling fashion” y cuando no se especifica la opcion minimize_downtime
Los pasos serían:
$ CRS_home/crs/bin/crsctl stop cluster -all $ Grid_home/bin/crsctl status resource -t $ cd Oracle_home/OPatch/4519934/4519934 opatch apply # Grid_home/bin/crsctl start cluster -all (como root) $ Grid_home/bin/crsctl status resource -t
Tras esto ejecutamos los post-scripts que nos diga el readme.

Rolling Patching

El método de Rolling patching es el método mas eficiente para la aplicación de parches en un RAC o un GRID. En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
De esta forma el downtime es cero ya que siempre dejas un nodo disponible de cada instancia.
No todos los parches pueden ser aplicados mediante este método. Si no puede aplicarse es cuando tendrás que aplicar el “minimun downtime” o “all node”
Los pasos son:
opatch query -is_rolling_patch $ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramostodo) opatch apply [-local_node rac1] -remote_nodes rac2, rac3 Arrancamos los nodos que hemos parcheado Comprobamos el estado con crsctl stat res –t Repetimos lospasos 2-5 en los que quedan Ejecutamos los comandos post-pacth

Minimun Downtime

Este método es el casi igual que el de rolling patching, pero lo llevamos a cabo cuando losparches no sean “rolling patch”La diferencia principal es que los nodos que se van parando y arrancando son los que tienen un mismo servicio.Se pierde servicio enlos nodos parcheados, pero si hay mas de un servicio el resto sigue funcionando. Es una mezcla entre el mejor (rolling) y el peor(all nodes)
En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
Los pasos son:
Elegimos un grupo de onodos aparchear. $ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramos todo) opatch apply -minimize_downtime Arrancamos los nodos que hemos parcheado Comprobamos el estado con crsctl stat res –t Repetimos lospasos 2-5 en los que quedan Ejecutamos los comandos post-pacth

A groso modo esta es la diferencia entre los 3 métodos de parchado de un RAC, evidentemente, como siempre, conviene leerse el README tanto para ver las especificaciones del parche, como la vuelta atrás.
Antes de ejecutar los comandos que ponemos aquí, es siempre recomendable el hacer las propias comprobaciones previas con el Opatch tal y como indicábamos en la entrada para ver si la instalación cumple con los requisitos del parche.

Dba stuff

Un cajon desastre para el día a día

Archivo de la etiqueta: patching

Version del parcheado de la base de datos