All Things Oracle

De cómo un clon nos puede ayudar con un patch

Si vamos a aplicar un patch o un patch set, una de las tareas previas es detener todos los procesos que estén ejecutándose en el Oracle home directory involucrado. Esto implica que debemos dejar de prestar servicio para iniciar el patching, proceso que si bien es relativamente fácil y sencillo, está sujeto a eventuales fallas que, de ocurrir, pueden llevar a una situación de crisis en la cual el DBA debe identificar el problema y tratar de resolverlo, u optar por dar marcha atrás.

Para evitar pasar por una situación como esta, es una buena práctica proceder al patching sobre un Oracle home directory nuevo, uno que sea un Clon del que está en producción, y así no tener que suspender el servicio sino hasta que estemos seguros de que la primera parte del patching se ha logrado de forma satisfactoria.

A continuación veremos cómo en solo 3 pasos, podemos tener en pocos minutos un Clon completamente soportado y listo para ser objeto del patching.

Clonación al estilo Oracle

Antes de iniciar la clonación, tomemos en cuenta las siguientes suposiciones iniciales:

  • Oracle home directory original: /u01/app/oracle/product/10.2.0/db_1
  • Oracle home directory clonado: /u01/app/oracle/product/10.2.0/db_2

1. Copiar el software desde el Oracle home directory original hacia el clonado.

Esto se debe hacer como el usuario root para que los permisos no se pierdan durante el proceso.

[root@urania ~]# cp -Rp /u01/app/oracle/product/10.2.0/db_1 /u01/app/oracle/product/10.2.0/db_2
Si la clonación se realizará en otro servidor, puedes usar tar para generar un archivo con los contenidos del Oracle home directory original:
[root@urania ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@urania db_1]# tar -cvf /stage/10gR2.tar .
Luego transfieres el archivo generado (con ftp por ejemplo) y una vez esté disponible en el nuevo servidor lo reconstituyes:
[root@caliope ~]# cd /u01/app/oracle/product/10.2.0/db_1
[root@caliope db_1]# tar -xvf /stage/10gR2.tar

2. Clonar la instalación con Oracle Universal Installer (OUI).

Esta parte se hace con el usuario oracle. Existen 2 formas de hacerlo, ambas producen el mismo resultado:

a. Usando clone.pl

[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Properties file /config/cs.properties was not found. Failed loading correponding properties../runInstaller -silent -clone -waitForCompletion "ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_2" "ORACLE_HOME_NAME=OraDb10g_home2"
Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_02-14-44PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 14:15:07 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 14:15:20 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 14:17:14 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 14:17:21 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_02-14-44PM.log' for more details.
b. Usando runInstaller
[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/oui/bin
[oracle@urania bin]$ ./runInstaller -clone -silent -ignorePreReq ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-01-31_04-10-24PM. Please wait ...Oracle Universal Installer, Version 10.2.0.1.0 Production
Copyright (C) 1999, 2005, Oracle. All rights reserved.

You can find a log of this install session at:
 /u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log
............................................................... 100% Done.

Installation in progress (Sat Jan 31 16:10:49 PET 2009)
.........................................................................
Install successful

Linking in progress (Sat Jan 31 16:11:03 PET 2009)
.                                                                74% Done.
Link successful

Setup in progress (Sat Jan 31 16:13:03 PET 2009)
....................                                            100% Done.
Setup successful

End of install phases.(Sat Jan 31 16:13:08 PET 2009)
WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.

The cloning of OraDb10g_home2 was successful.
Please check '/u01/app/oracle/oraInventory/logs/cloneActions2009-01-31_04-10-24PM.log' for more details.
Si estamos clonando un Oracle home directory en 11g debemos tener en cuenta que es requerido indicar también ORACLE_BASE:
[oracle@urania ~]$ cd /u01/app/oracle/product/10.2.0/db_2/clone/bin
[oracle@urania bin]$ perl clone.pl ORACLE_BASE="/u01/app/oracle" ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_2" ORACLE_HOME_NAME="OraDb10g_home2"

3. Ejecutar los scripts de configuración requeridos en el paso anterior.

Si la clonación se ha realizado sobre un servidor que ya tenía Oracle installado, el mensaje que se obtiene al concluir el paso previo es:

WARNING:The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.
En caso se hubiese tratado de un servidor en el cual se está instalando Oracle por primera vez, se obtiene:
WARNING:A new inventory has been created in this session. However, it has not yet been registered as the central inventory of this system.
To register the new inventory please run the script '/u01/app/oracle/oraInventory/orainstRoot.sh' with root privileges.
If you do not register the inventory, you may not be able to update or patch the products you installed.

The following configuration scripts
/u01/app/oracle/product/10.2.0/db_2/root.sh
need to be executed as root for configuring the system.
Cualquiera fuese el caso, hay que ejecutar los respectivos scripts bajo el usuario root, asumiendo que se trata del último caso:
[root@caliope ~]# sh /u01/app/oracle/oraInventory/orainstRoot.sh

Changing permissions of /u01/app/oracle/oraInventory to 770.
Changing groupname of /u01/app/oracle/oraInventory to oinstall.
The execution of the script is complete
[root@caliope ~]# sh /u01/app/oracle/product/10.2.0/db_2/root.sh

Running Oracle10 root.sh script...

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/10.2.0/db_2

Enter the full pathname of the local bin directory: [/usr/local/bin]:
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root.sh script.
Now product-specific root actions will be performed.

¡Felicitaciones!, si llegaste a éste punto entonces ya tienes un Oracle home directory debidamente clonado sobre el cual puedes aplicar el patch o patch set que necesitas, sin tener que suspender el servicio (por el momento).

En cuanto termines el patching sobre este Oracle home directory ya puedes suspender el servicio (de ser necesario) y seguir con los pasos restantes que se señalen en el archivo Installation Notes que acompaña al patch/patch set.

Conclusiones

Es altamente recomendable realizar el patching sobre un Clon del Oracle home directory original. Esto permite retrasar la suspensión del servicio hasta el momento en que tengamos el patch debidamente aplicado sobre el software, así nos evitaremos desagradables situaciones de tensión en caso algo salga mal.

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o ¡contáctame ahora mismo!

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Posts Relacionados

Primer post de una serie dedicada al arte de parchar Oracle. Empezamos con el parchado in-place, la forma más común y también la más peligrosa.
Aprenda a descargar los parches de Oracle, tanto manualmente como de forma automatizada, usando el utilitario getMOSPatch.
Link a articulo publicado en Toad World, sobre como aplicar un patch out-of-place a Grid Infrastructure, usando un Golden Image.

¿Necesitas Ayuda?

Completa estos datos y estaré en contacto a la brevedad.