En el episodio anterior mostramos como aplicar parches directamente en el Oracle Home en uso, proceso conocido como parchado in-place, proceso que se ha demostrado como largo, tedioso, y que demanda una larga suspensión del tiempo de servicio.
Afortunadamente existe una mejor forma de aplicar parches, que se presenta a continuación.
Parchado out-of-place
Recibe este nombre la forma recomendada de aplicar parches, y que implica trabajar sobre un nuevo Oracle Home (en adelante OH) que contendrá los ejecutables parchados.
Veamos cómo se desarrolla un ciclo de parchado bajo esta modalidad.
Situación inicial
Contamos con un servidor llamado server1, en el cual se tiene instalado Oracle Database Server 19c, en un Oracle Home llamado DBHome1, que da soporte a una base de datos single instance.
$ echo $ORACLE_HOME
/u01/app/oracle/19.0.0/db_1Este OH tiene aplicados los siguientes parches:
| 34765931 database release update 19.18.0.0.0 |
| 34786990 ojvm release update 19.18.0.0.0 |
| 34777391 jdk bundle patch 19.0.0.0.230117 |
| 35573556 database mrp 19.18.0.0.230718 |
| 34972375 datapump bundle patch 19.18.0.0.0 |
1
2
Creación de nuevo Oracle Home
Se crea un directorio que luego se asociará con un Oracle Home llamado DBHome2.
$ mkdir /u01/app/oracle/19.0.0/db_2
Instalación de Oracle Database
Se procede a descomprimir el software base de Oracle Database 19c en el directorio recién creado.
$ export DB_HOME=/u01/app/oracle/19.0.0/db_2
$ export STAGE=/stage
$ unzip -oq ${STAGE}/LINUX.X64_193000_db_home.zip -d ${DB_HOME}
$ rm -rf ${DB_HOME}/OPatch
$ unzip -oq ${STAGE}/p6880880_190000_Linux-x86-64.zip -d ${DB_HOME}Luego de esto tenemos los binarios de Oracle Database 19.3 en el nuevo directorio.
3
4
Parchado del nuevo Oracle Home
Se procede a aplicar los siguientes parches:
| 36233263 database release update 19.23.0.0.0 |
| 36199232 ojvm release update 19.23.0.0.0 |
| 36195566 jdk bundle patch 19.0.0.0.240416 |
| 36701173 database mrp 19.23.0.0.240618 |
| 36420641 datapump bundle patch 19.23.0.0.0 |
$ ${DB_HOME}/runInstaller -silent -printtime \
-waitforcompletion -ignorePrereqFailure \
ORACLE_HOME_NAME="DBHome2" -applyRU ${STAGE}/36233263 \
-applyOneOffs ${STAGE}/36199232,${STAGE}/36195566,${STAGE}/36420641 \
-responseFile ${DB_HOME}/install/response/db_install.rsp \
INVENTORY_LOCATION=/u01/app/oraInventory \
UNIX_GROUP_NAME=oinstall \
ORACLE_BASE=/u01/app/oracle \
oracle.install.option=INSTALL_DB_SWONLY \
oracle.install.db.InstallEdition=EE \
oracle.install.db.OSDBA_GROUP=dba \
oracle.install.db.OSBACKUPDBA_GROUP=backupdba \
oracle.install.db.OSDGDBA_GROUP=dgdba \
oracle.install.db.OSKMDBA_GROUP=kmdba \
oracle.install.db.OSRACDBA_GROUP=racdba \
oracle.install.db.rootconfig.executeRootScript=false
$ opatch napply ${STAGE}/36701173 -oh ${DB_HOME} -silent
$ sudo /u01/app/oracle/19.0.0/db_2/root.sh
Suspensión del servicio
Para poder usar el nuevo OH, obligatoriamente se tiene que bajar la base de datos como primer paso.
SQL> shutdown immediate;
5
6
Parchado de la base de datos
Se actualizan las variables de entorno para referenciar al nuevo OH, y luego de ello ya se puede continuar con la actualización del catálogo de la base de datos, usando el utilitario datapatch.
$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_2
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.
SQL> startup;
$ datapatch -verboseSituación final
7
Ventajas del parchado out-of-place
1. Mínimo tiempo sin servicio
Como se está usando un nuevo Oracle Home, todo el tiempo que tome prepararlo no afecta la disponibilidad del servicio, a diferencia de lo que ocurre con el parchado in-line.
La suspensión del servicio se limita al momento en el cual se debe hacer uso de los nuevos binarios, con el cambio de OH, y con ello la actualización del catálogo con datapatch:
SQL> shutdown immediate;
$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_2
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.
SQL> startup;
$ datapatch -verboseA continuación los tiempos que registré en mi ambiente de pruebas, en el que solamente apliqué Release Updates/RU (sin Monthly Recommended Patches/MRP o one-offs adicionales). Se muestra tanto el tiempo que toma para la opción in-place como para la out-of-place:
2. Mínimo espacio consumido
A continuación el espacio consumido que registré en mi ambiente de pruebas, en el que solamente apliqué los Release Updates/RU (sin Monthly Recommended Patches/MRP o one-offs adicionales). Se muestra tanto el espacio que toma para la opción in-place como para la out-of-place:
Ya que por cada parche aplicado, Oracle debe obtener un respaldo de todos los objetos modificados, se hace evidente que el espacio ocupado se va incrementando con la aplicación in-place de cada nuevo RU, mientras que para out-of-place el espacio es mucho menor y estable.
3. Simplicidad en caso de rollback
Si por alguna razón necesitamos deshacer la aplicación del parchado, simplemente debemos regresar al OH anterior y actualizar el catálogo, nuevamente con mínima suspensión del servicio:
SQL> shutdown immediate;
$ export ORACLE_HOME=/u01/app/oracle/19.0.0/db_1
$ export PATH=${ORACLE_HOME}/bin:${PATH}:.
SQL> startup;
$ datapatch -verboseConclusiones
Si bien quizás no es la modalidad más usada por los DBAs, el parchado out-of-place es por lejos la más eficiente, demanda poco espacio en disco, y lo que es mejor: presenta los tiempos de indisponibilidad del servicio más bajos.
En el siguiente episodio veremos cómo simplificar aún más el parchado out-of-place, así que estén atentos!
Una respuesta
Interesante articulo !!!!