blog

Desde principios del pasado año Oracle empezó a publicar, cada tres meses, los PSU “Patch Set Updates”. Esto es un conjunto de parches a aplicar sobre las últimas versiones de cada producto.

Estos “PSU”, los componen los parches para bugs que han afectado a mas usuarios y los que Oracle considera como mas importantes. Los “PSU” también incluyen los “CPU” o Critical Patch Update que venían apareciendo hasta la fecha de manera periódica.

Para que un parche pueda entrar en un PSU debe de cumplir varias condiciones.

• No tiene que implicar cambios de comportamiento del producto (para que en BBDD, por ejemplo, no sea necesario testear nuevamente las aplicaciones ya que no hay cambios en el comportamiento del optimizador).
• No debe requerir reconfigurar el producto
• Tiene que ser “rolling RAC” (esto es, que se pueden instalar sin pérdida del servicio en BBDD Oracle RAC) *

*No del todo cierto, ya que por ejemplo al aplicar el PSU para BBDD existe un punto en el que es necesario recompilar todas las vistas de la BBDD. Esto provoca una descompilación masiva de objetos y es prácticamente imposible que no afecte a los usuarios (es necesaria una parada).

Por contrapartida tenemos que decir que esta tarea de “compilación de vistas” solo se realiza con el primer PSU que se aplica a BBDD, en el siguiente ya no será necesario. Por ejemplo si lo hicimos con el PSU 10.2.0.4.1 ya no es necesario ejecutarlo nuevamente al aplicar el 10.2.0.4.3.

Otro caso en el que no es posible aplicar el parche sin paradas es cuando el software oracle esta compartido entre las instancias (los binarios a sustituir no pueden estar en uso).

Notar que son acumulativos, en consecuencia si aplicamos el PSU 10.2.0.4.3 no es necesario aplicar los anteriores y finalmente que son de bajo riesgo (se han probado de manera intensiva para evitar “efectos adversos”).

Actualmente existen PSU en plataformas UNIX/Linux para los productos:

• CRS (Clusterware)
• BBDD
• Enterprise Manager Grid Control
• Agente de Grid Control

En el caso de Windows se dispone de otro tipo de grupos de parches llamados “Bundles”.

Cada producto dispone de sus versiones de PSU particulares (cada versión de gestor de BBDD también puede disponer de PSU diferentes)

Antes de aplicar cualquiera de estos PSU o Bundles, es muy recomendable actualizar Opatch a la última versión disponible, en muchos casos la documentación del PSU o Bundle especifica la mínima versión de OPatch necesaria.

Estos PSU se pueden aplicar de tres maneras, que de mas simple a más compleja serian, via Grid Control, de manera “automatica” con OPatch o manualmente con OPatch.

Finalmente notar que los PSU de CRS acostumbran a aplicarse no solo al home de CRS sino también a los de las BBDD que controla el CRS (en los homes de BBDD existe la parte de cliente del software de cluster), esto lo podremos hacer siempre y cuando CRS y BBDD tengan “exactamente” la misma versión.

Notar que si tenemos que aplicar varios Patchsets/PSU/parches podemos realizar primero las tareas de instalación de binarios de todos ellos (en el orden mencionado) para posteriormente lanzar los scripts (o tareas de post instalación) en el mismo orden que se han instalado los binarios, minimizando el numero de reinicios necesarios.

Como punto final os muestro los comandos para parchear un Clusterware 10.2.0.4, en una instalación de dos nodos con una BBDD RAC de la misma versión que el CRS. Usaremos el ultimo PSU 10.2.0.4.2, lo haremos de manera manual con OPatch y con “rolling RAC”, esto es sin perdida de servició (en todo momento como mínimo un nodo estará en marcha).

Aplicar PSU 10.2.0.4.2 a Clusterware 10.2.0.4 con “rolling RAC”

OPatch

Como paso previo tenemos que actualizar OPatch en todos los homes, lo podemos hacer “en caliente”. Consiste en bajar la última revisión de OPatch correspondiente al producto Oracle y descomprimir el zip en el oracle home. En nuestro caso lo hago tanto en el home de CRS como de BBDD.

En esta imagen tenemos el link de metalink que nos permite bajar el Opatch para productos 10.2 en HPUX Itanium, todas las versiones de Opatch para todas las plataformas las tenemos agrupadas bajo el parche numero 6880880.

Realizo esta tarea en los homes de todos los nodos en este primer paso, podría hacerlo nodo a nodo previamente al PSU.

Estas serian las versiones de OPatch correspondientes a cada versión de producto:

Oracle 9.2 and 10.1 – OPatch 101000
Oracle 10.2 – OPatch 102000
Oracle 11.1 – OPatch 111000
Oracle 11.2 – OPatch 112000

Si no lo hemos hecho antes, nos bajamos el PSU

Tareas “pre” patch

Estas son las tareas previas, consistentes en parar el software del nodo, cambiar permisos y guardar información de configuración tanto de CRS como de BBDD (parchearemos ambos).

• Paramos los productos Oracle (mediante srvctl) y el clusterware (crsctl stop crs) en el primero de los nodos
• Ejecutamos los scripts “pre” patch (suponiendo que hemos descomprimido el parche en /home/oracle)

Como usuario “root”  y suponiendo que “oracle” es el propietario de los binarios de CRS.

/home/oracle/8705958/custom/scripts/prerootpatch.sh -crshome /oracle/product/10.2.0/crs -crsuser oracle

Como usuario “oracle”

 

/home/oracle/8705958/custom/scripts/prepatch.sh -crshome /oracle/product/10.2.0/crs

Este solo si la BBDD es de la misma versión que el clusterware:

 

/home/oracle/8705958/custom/server/8705958/custom/scripts/prepatch.sh -dbhome /oracle/product/10.2.0/db_1

• Parchearemos los binarios de CRS

Aseguramos tener las variables de entorno correctas para el CRS, y el opatch en el PATH, nos movemos al directorio en el que tenemos el parche y ejectamos “opatch”. Usamos el parámetro -local para evitar que intente aplicar el parche en el resto de nodos.

[oracle@server1 ~]$ . ./crs.env
[oracle@server1 ~]$ cd 8705958/
[oracle@server1 8705958]$ opatch napply -local -oh /oracle/product/10.2.0/crs -id 8705958

Llegaremos a un punto en el que nos pide una dirección de correo para el OCM (Oracle Configuration Manager), en caso de no usar esta funcionalidad simplemente le daremos al “return”, nos pedira confirmación de que no la queremos configurar y podremos seguir.

Repetimos la operación en el home de BBDD, siempre que esta sea de la misma versión que el clusterware. La parte de parche de la BBDD se encuentra en el mismo directorio del parche, dentro de las carpetas “custom/server”. El procedimiento es idéntico al anterior.

opatch napply /home/oracle/8705958/custom/server/ -local -oh /oracle/product/10.2.0/db_1 -id 8705958

• Ejeutamos los scripts “post patch” como usuario oracle, para CRS y BBDD

Estos scripts realizan las tareas de reconfiguración de los ficheros y cambian permisos.

/home/oracle/8705958/custom/scripts/postpatch.sh -crshome /oracle/product/10.2.0/crs

/home/oracle/8705958/custom/server/8705958/custom/scripts/postpatch.sh -dbhome /oracle/product/10.2.0/db_1

• Finalmente y como root establecemos permisos y arrancamos clusterware

/home/oracle/8705958/custom/scripts/postrootpatch.sh -crshome /oracle/product/10.2.0/crs

Este ultimo script pondrá en marcha nuevamente el clusterware, por lo que hay que tener en cuenta que todos los servicios que se arranquen de manera automática con el también arrancaran. Si nos interesa que por alguna razón que ciertos componentes no arranquen (para aplicar mas parches posteriormente, por ejemplo) tendremos que desactivar previamente el componente.

• Es el momento de pasar al siguiente nodo y volver a empezar el procedimiento

Una vez parcheados todos los nodos podemos dar el proceso por finalizado.

Para comprovar la instalación del parche en cualquiera de ellos podemos usar el comando:

opatch lsinventory

Ya disponemos de un Clusterware “a la ultima”.