INSTALAR PSU ORACLE 19.17.0.0.221018

Nivel del post no aplicainicialintermedioavanzado
SGBD oraclemysqlmariadbMySQL/MariaDBpostgresqlno aplica

Tiempo de lectura aproximado 19min

En esta entrada vamos a explicar como instalar el PSU Oracle 19.17.00221018 para GRID y BBDD, el parche liberado para la versión 19c de Oracle en octubre del 2022 (34416665).

Si, indudablemente una de las tareas de cualquier DBA que se precie es realizar el parcheo de las bases de datos que administra, siendo indiferente que el entorno sea productivo o no. Porque recuerda que los malos siempre están al acecho y una de tus prioridades debe ser mantener los datos lo más seguros posibles. Y aunque ese concepto sea una combinación de varios equipos de trabajo (como Unix/Wintel, seguridad, networking…), nosotros siempre podremos aportar un granito de arena. Y en esos granitos, se encuentra la instalación de parches del fabricante (que corrigen vulnerabilidades, arreglan bugs, etc).

Descripción del escenario

Para entender bien este procedimiento, en nuestra cabeza debemos tener claro el escenario donde vamos a trabajar: un entorno RAC (Real Application Clusters), con un DataGuard montado entre ambos entornos (principal y emergencias). Cada entorno consta de dos nodos. El esquema gráfico sería el siguiente:

Es importante recalcar que los servidores que albergan las BBDD usan un sistema operativo Linux, por lo que el proceso será explicado en este entorno. Además, fíjate que tenemos un entorno principal y otro standby -o emergencias-, por lo que el proceso debe ser tal que así:

  1. Aplicar parches en el entorno standby (BDSTBY1/BDSTBY2)
  2. Realizar un switchover, dejando como entorno principal el antiguo standby
  3. Aplicar parches en el nuevo entorno standby, que originalmente era principal (BDPRIN1/BDPRIN2)
  4. Realizar otro switchover para volver a dejar los entornos como estaban

Ahora que sabemos donde estamos trabajando, pasamos a la acción.

Descargar el software necesario

Para este parcheo, necesitaremos dos paquetes: la versión 12.2.0.1.32 o superior de la herramienta OPatch y el propio parche, en nuestro caso p34416665_190000_Linux-x86-64. Para el parche, debemos acceder a Oracle Support y descargarlo. Para la herramienta OPatch, puedes ir aquí.

Además, debes tener instalada y actualizada la versión de AHF (Autonomous Health Framework) que contiene, entre otras herramientas, el conocido TFA (Trace File Analyzer). Te dejo el enlace de descarga justo aquí.

Deberás subir todos los .zip a los nodos y entornos a parchear. Es decir, siguiendo el escenario de ejemplo planteado antes, tienes que subir los tres .zip (OPatch, parche y AHF) a BDPRIN1, BDPRIN2, BDSTBY1 y BDSTBY2.

Pasos previos

Bien, ya tenemos todo el software subido a nuestras máquinas a parchear. Vamos a enumerar ahora las tareas previas al propio parcheo, como es: instalar/actualizar AHF, bajar las instancias de bases de datos, parar el listener, etc.

Instalar o actualizar Oracle AHF

Este paso previo es necesario antes de empezar el parcheo de nuestras bases de datos. Pero no te asustes que son, como decimos en el sur, tres chuminás (o, dicho de otro modo, una tontería). Debo aclararte que en mi experiencia realizando este paso, he descubierto que siempre me ahorra muchos quebraderos de cabeza el desinstalar la versión previa y volviéndola a instalar. Seguramente esto sea discutible e, incluso, mejorable. Pero repito: mi experiencia propia.

Por cierto, un detallito importante: este proceso se realiza con usuario root.

Lo primero que haremos es desinstalar la versión previa de AHF:

[root@bdstby1 ~]# ahfctl uninstall

Vale. Ahora, vamos a crear el directorio que contendrá el software. Por defecto, el instalador te dirá de ubicarlo en la carpeta /opt, pero yo prefiero crearlo en otro sitio. Como tengo un filesystem dedicado a Oracle, voy a hacerlo ahí:

[root@bdstby1 ~]# mkdir /oracle/oracle.ahf

Siguiente paso, descomprimir el zip (como lo subí al home de mi usuario, ahí mismo lo descomprimo):

[root@bdstby1 ~]# cd /home/pdelgado
[root@bdstby1 pdelgado]# mkdir ahf_oracle
[root@bdstby1 pdelgado]# unzip -d ./ahf_oracle AHF-LINUX_v23.2.0.zip

Como ves, hemos creado una carpeta dentro de mi home que se llama ahf_oracle y ahí he descomprimido el zip. Ahora, entramos a dicha carpeta y lanzamos la instalación.

[root@bdstby1 pdelgado]# ./ahf_setup

AHF Installer for Platform Linux Architecture x86_64

AHF Installation Log : /tmp/ahf_install_222400_21770_2022_09_27-13_28_32.log

Starting Autonomous Health Framework (AHF) Installation

AHF Version: 22.2.4 Build Date: 202209092344

Default AHF Location : /opt/oracle.ahf

Do you want to install AHF at [/opt/oracle.ahf] ? [Y]|N : N

Please Enter new AHF Location : /oracle/oracle.ahf/ 

AHF Location : /oracle/oracle.ahf

AHF Data Directory stores diagnostic collections and metadata.
AHF Data Directory requires at least 5GB (Recommended 10GB) of free space.

Choose Data Directory from below options : 

1. /oracle/app/base [Free Space : 151152 MB]
2. /oracle/oracle.ahf [Free Space : 151152 MB]
3. Enter a different Location

Choose Option [1 - 3] : 3

Please Enter AHF Data Directory : /oracle/oracle.ahf

AHF Data Directory : /oracle/oracle.ahf/data

Do you want to add AHF Notification Email IDs ? [Y]|N : N

AHF will also be installed/upgraded on these Cluster Nodes :

1. bdstby2

The AHF Location and AHF Data Directory must exist on the above nodes
AHF Location : /oracle/oracle.ahf
AHF Data Directory : /oracle/oracle.ahf/data

Do you want to install/upgrade AHF on Cluster Nodes ? [Y]|N : Y

Extracting AHF to /oracle/oracle.ahf

Configuring TFA Services

Discovering Nodes and Oracle Resources

Not generating certificates as GI discovered

Starting TFA Services
Created symlink /etc/systemd/system/multi-user.target.wants/oracle-tfa.service  /etc/systemd/system/oracle-tfa.service.
Created symlink /etc/systemd/system/graphical.target.wants/oracle-tfa.service  /etc/systemd/system/oracle-tfa.service.

.-----------------------------------------------------------------------------.
| Host     | Status of TFA | PID   | Port | Version    | Build ID             |
+----------+---------------+-------+------+------------+----------------------+
| bdstby1  | RUNNING       | 24010 | 5000 | 22.2.4.0.0 | 22240020220909234452 |
'----------+---------------+-------+------+------------+----------------------'

Running TFA Inventory...

Adding default users to TFA Access list...

.---------------------------------------------------------.
|               Summary of AHF Configuration              |
+-----------------+---------------------------------------+
| Parameter       | Value                                 |
+-----------------+---------------------------------------+
| AHF Location    | /oracle/oracle.ahf                    |
| TFA Location    | /oracle/oracle.ahf/tfa                |
| Orachk Location | /oracle/oracle.ahf/orachk             |
| Data Directory  | /oracle/oracle.ahf/data               |
| Repository      | /oracle/oracle.ahf/data/repository    |
| Diag Directory  | /oracle/oracle.ahf/data/bdprin1/diag  |
'-----------------+---------------------------------------'

Starting Orachk Scheduler from AHF

AHF install completed on bdstby1 

Installing AHF on Remote Nodes :

AHF will be installed on bdstby2, Please wait.

Installing AHF on bdstby2 :

[bdstby2] Copying AHF Installer

[bdstby2] Running AHF Installer


AHF binaries are available in /oracle/oracle.ahf/bin

AHF is successfully installed

Do you want AHF to store your My Oracle Support Credentials for Automatic Upload ? Y|[N] : N

Moving /tmp/ahf_install_222400_21770_2022_09_27-13_28_32.log to /oracle/oracle.ahf/data/bdstby1/diag/ahf/

[root@bdstby1 pdelgado]#

Aquí tienes la salida de todo el proceso. Las líneas a las que debes prestar atención son las siguientes:

  • Línea 13: te pregunta si quieres instalar AHF en la localización por defecto, por lo que respondemos que no (N).
  • Línea 15: introducimos la nueva locación que, como dijimos antes, sería /oracle/oracle.ahf/
  • Línea 28: debemos indicar la localización para el directorio data, así que introducimos el nº 3.
  • Línea 30: el mismo directorio que pusimos en la línea 15, pero sin la barra final.
  • Línea 34: solicita los emails de notificación, así que respondemos que no (N).
  • Línea 44: tras comprobar que tenemos un segundo nodo que forma parte del clúster, nos avisa de que el directorio de /oracle/oracle.ahf debe existir en ese segundo nodo y nos pregunta si queremos instalar/actualizar AHF en el resto de nodos del clúster. Podemos responder que si (Y) para que el proceso sea automático o no (N) para instalar de manera manual el software en el otro nodo.
  • Línea 100: por último, nos pregunta si queremos introducir nuestras credenciales de My Oracle Support para actualizaciones automáticas. Respondemos que no (N).

Una vez llegados a este punto, debemos tener en cuenta que según nuestra decisión de instalar AHF de forma manual en cada nodo o de manera automática, habremos acabado con él o deberemos repetir todo este proceso en cada nodo.

Descomprimir el parche de GRID y BBDD

Sigamos. Ahora vamos a descomprimir el zip que contiene los parches para el GRID y la BBDD (p34416665_190000_Linux-x86-64.zip) ya que el OPatch lo descomprimiremos directamente sobre el ORACLE_HOME de cada uno.

Recordamos que tenemos un filesystem solo para Oracle. Yo, además, tengo una carpeta dentro llamada software donde tengo los binarios de la instalación original (que nunca se sabe), así como el parche actual que voy a aplicar y el inmediatamente anterior. Este paso podemos hacerlo de dos formas: con el usuario propietario del directorio (que en mi caso es oracle) o con root (para evitar problemas de permisos). Si lo haces con root, recuerda aplicar un chown -R y listo. Yo te lo voy a explicar con el usuario oracle.

[oracle@bdstby1 ~]$ cd /oracle/software/
[oracle@bdstby1 ~]$ mkdir parche_octubre22
[oracle@bdstby1 ~]$ cd parche_octubre22
[oracle@bdstby1 ~]$ cp /home/pdelgado p*.zip .
[oracle@bdstby1 ~]$ unzip -q p34416665_190000_Linux-x86-64.zip
[oracle@bdstby1 ~]$ ls -la
total 2663428
drwxr-xr-x.  3 oracle oinstall        126 Dec 14 10:11 .
drwxr-xr-x. 12 oracle oinstall       4096 Dec 14 10:08 ..
drwxr-x---.  8 oracle oinstall        159 Abr 05 14:17 33182768
-rw-r--r--.  1 oracle oinstall 2604734217 Abr 05 10:09 p33182768_190000_Linux-x86-64.zip
-rw-r--r--.  1 oracle oinstall  122247289 Abr 05 10:10 p6880880_190000_Linux-x86-64.zip
-rw-rw-r--.  1 oracle oinstall     359632 Abr 05 14:17 PatchSearch.xml

Bien, como podemos ver, hemos creado una carpeta llamada parche_octubre22 y ahí he movido y descomprimido el parche.

Desactivar la aplicación de redos en la standby

Ahora vamos a desactivar la aplicación de redos en nuestra base de datos de emergencias (la que está en standby). Para ello, vamos a cargar el profile de base de datos y entramos a la herramienta del broker:

[oracle@bdprin1 patches]$ cd ~
[oracle@bdprin1 ~]$ . ./.profile_BBDD
[oracle@bdprin1 ~]$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Apr 5 14:11:03 2023
Version 19.17.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/mipassword
Connected to "BBDD"
Connected as SYSDBA.
DGMGRL> show configuration

Configuration - bbdd_dg

  Protection Mode: MaxAvailability
  Members:
  bbdd      - Primary database
    bbdd_emer - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 40 seconds ago)

DGMGRL> show database bbdd_emer

Database - bbdd_emer

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          0 seconds (computed 0 seconds ago)
  Average Apply Rate: 82.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    BBDD1 (apply instance)
    BBDD2

Database Status:
SUCCESS

DGMGRL> edit database bbdd_emer set state='APPLY-OFF';
Succeeded.
DGMGRL> show database bbdd_emer

Database - bbdd_emer

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-OFF
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          (unknown)
  Average Apply Rate: (unknown)
  Real Time Query:    OFF
  Instance(s):
    BBDD1 (apply instance)
    BBDD2

Database Status:
SUCCESS

DGMGRL> exit

Listo, aplicación de redos en la standby parada.

Parada de la bbdd y del listener

Como estamos trabajando en un entorno RAC, vamos a poder parar a nivel de servicio las instancias de base de datos y listener en los nodos del entorno con la herramienta srvctl. Primero, veamos que instancias y listener están corriendo:

[oracle@bdstby1 ~]$ ps -fea | grep pmon
oracle    3882     1  0 Nov17 ?        00:01:15 asm_pmon_+ASM1
oracle   24668  3443  0 11:36 pts/0    00:00:00 grep --color=auto pmon
oracle   27304     1  0 Dec13 ?        00:00:03 ora_pmon_BBDD1

[oracle@bdstby1 ~]$ ps -fea | grep tns
root       109     2  0 Nov17 ?        00:00:00 [netns]
oracle    3608     1  0 Nov17 ?        00:02:01 /oracle/app/grid/19300/bin/tnslsnr LISTENER -no_crs_notify -inherit
oracle    3614     1  0 Nov17 ?        00:00:34 /oracle/app/grid/19300/bin/tnslsnr LISTENER_DG -no_crs_notify -inherit
oracle    3670     1  0 Nov17 ?        00:00:48 /oracle/app/grid/19300/bin/tnslsnr LISTENER_SCAN1 -no_crs_notify -inherit
oracle    3685     1  0 Nov17 ?        00:06:37 /oracle/app/grid/19300/bin/tnslsnr ASMNET1LSNR_ASM -no_crs_notify -inherit
oracle   24693  3443  0 11:37 pts/0    00:00:00 grep --color=auto tns

Estupendo, tenemos corriendo la instancia de bases de datos, el ASM y varios listener. Nosotros solo vamos a parar la instancia de bases de datos y el listener de la misma, junto al del dataguard. Como hemos dicho, usamos la herramienta srvctl. Primero, veamos el estado de las instancias:

[oracle@bdstby1 ~]$ srvctl status database -d bbdd_emer
Instance BBDD1 is running on node bdprin1
Instance BBDD2 is running on node bdprin2

Ahora, lanzamos la misma herramienta para detener la base de datos y el listener:

[oracle@bdstby1 ~]$ srvctl stop database -d bbdd_emer
[oracle@bdstby1 ~]$ srvctl status database -d bbdd_emer
Instance BBDD1 is not running on node bdprin1
Instance BBDD2 is not running on node bdprin2
[oracle@bdstby1 ~]$ srvctl stop listener -l LISTENER
[oracle@bdstby1 ~]$ srvctl stop listener -l LISTENER_DG

Parcheo del GRID y de la base de datos

Pasamos ahora a las tareas correspondiente al parcheo del GRID y la base de datos. Si observamos el readme.html que acompaña nuestro parche anteriormente descomprimido, veremos el siguiente cuadro informativo:

Si nos fijamos, nos indica que para el GRID debemos instalar los subpatches 34428761, 34580338 y 33575402. Para la base de datos, los subpatches 34419443 y 34444834.

En este fichero readme, además, tienes detallados todos los pasos a seguir tanto para la instalación de los parches como para realizar un rollback en caso necesario.

Recordad que tenemos esto descomprimido en /oracle/software/parche_octubre22. Y que debemos realizar estos pasos en todos los nodos del entorno (en nuestro escenario, dos).

Un último apunte: las tareas de parcheo del GRID deben realizarse con el usuario root.

Aplicar nuevo OPatch en el GRID

Lo primero que debemos hacer es actualizar la herramienta OPatch, un software desarrollado en Java que nos permite aplicar parches o, llegado el caso, realizar rollback si algo fallase. Entre sus utilidades, nos instalará también la herramienta opatchauto, la cual nos facilitará la instalación de los subpatches del GRID.

Comprobemos antes la versión de OPatch y el nivel de parches que tenemos:

[oracle@bdstby1 OPatch]$ ./opatch version
OPatch Version: 12.2.0.1.28

[oracle@bdstby1 OPatch]$ . /home/oracle/.profile_RAC

[oracle@bdprin1 OPatch]$ ./opatch lspatches
31335188;TOMCAT RELEASE UPDATE 19.0.0.0.0 (31335188)
31305087;OCW RELEASE UPDATE 19.8.0.0.0 (31305087)
31304218;ACFS RELEASE UPDATE 19.8.0.0.0 (31304218)
31281355;Database Release Update : 19.8.0.0.200714 (31281355)

Ahora tendremos que movernos al ORACLE_HOME del GRID y, como recomendación personal, yo siempre dejo la carpeta del OPatch actual renombrada como OPatch_old por si hay que volver atrás. La actual OPatch_old la borro y así sucesivamente.

[root@bdstby1 ~]# cd /oracle/app/grid/19300
[root@bdstby1 19300]# rm -rf OPatch_old
[root@bdstby1 19300]# mv OPatch OPatch_old
[root@bdstby1 19300]# chown -R oracle:oinstall OPatch_old/
[root@bdstby1 19300]# cp /oracle/software/parche_octubre22/p6880880_190000_Linux-x86-64.zip /oracle/app/grid/19300
[root@bdstby1 19300]# unzip -d /oracle/app/grid/19300 p6880880_190000_Linux-x86-64.zip
[root@bdstby1 19300]# chown -R oracle:oinstall OPatch

Bien, ahora que hemos actualizado OPatch, comprobemos la nueva versión:

[oracle@bdstby1 OPatch]$ ./opatch version
OPatch Version: 12.2.0.1.35

Parcheo del GRID usando opatchauto

Llega la hora de aplicar el parche al GRID, lo cual haremos usando la herramienta opatchauto. El comando que debemos usar es el siguiente:

[root@bdstby1 19300]# /oracle/app/grid/19300/OPatch/opatchauto apply /oracle/software/parche_octubre22/34416665 -oh /oracle/app/grid/19300

Fíjate que el comando está formado por la ruta completa de la herramienta OPatch, la palabra reservada apply, la ruta donde se encuentra el parche descomprimido y el ORACLE_HOME del GRID. Listo. Opatchauto se encargará de todo por ti. Te dejo aquí la salida del mismo:

OPatchauto session is initiated at Wed Abr 05 13:52:54 2023

System initialization log file is /oracle/app/grid/19300/cfgtoollogs/opatchautodb/systemconfig2023-04-05_01-52-57PM.log.

El archivo de log de sesión es /oracle/app/grid/19300/cfgtoollogs/opatchauto/opatchauto2023-04-05_01-53-05PM.log
El ID para esta sesión es YNB2

Executing OPatch prereq operations to verify patch applicability on home /oracle/app/grid/19300
Patch applicability verified successfully on home /oracle/app/grid/19300

Executing patch validation checks on home /oracle/app/grid/19300
Patch validation checks successfully completed on home /oracle/app/grid/19300

Performing prepatch operations on CRS - bringing down CRS service on home /oracle/app/grid/19300
Prepatch operation log file location: /oracle/app/base/crsdata/bdstby1 /crsconfig/crs_prepatch_apply_inplace_bdstby1 _2023-04-05_01-54-05PM.log
CRS service brought down successfully on home /oracle/app/grid/19300

Start applying binary patch on home /oracle/app/grid/19300
Binary patch applied successfully on home /oracle/app/grid/19300

Performing postpatch operations on CRS - starting CRS service on home /oracle/app/grid/19300
Postpatch operation log file location: /oracle/app/base/crsdata/bdstby1 /crsconfig/crs_postpatch_apply_inplace_bdstby1 _2023-04-05_02-03-22PM.log
CRS service started successfully on home /oracle/app/grid/19300

OPatchAuto correcto.

--------------------------------Summary--------------------------------

Patching is completed successfully. Please find the summary as follows:

Host:bdstby1 
CRS Home:/oracle/app/grid/19300
Version:19.0.0.0.0
Summary:

==Following patches were SUCCESSFULLY applied:

Patch: /oracle/software/parche_octubre22/34416665/33575402
Log: /oracle/app/grid/19300/cfgtoollogs/opatchauto/core/opatch/opatch2023-03-15_13-56-57PM_1.log

Patch: /oracle/software/parche_octubre22/34416665/34419443
Log: /oracle/app/grid/19300/cfgtoollogs/opatchauto/core/opatch/opatch2023-03-15_13-56-57PM_1.log

Patch: /oracle/software/parche_octubre22/34416665/34428761
Log: /oracle/app/grid/19300/cfgtoollogs/opatchauto/core/opatch/opatch2023-03-15_13-56-57PM_1.log

Patch: /oracle/software/parche_octubre22/34416665/34444834
Log: /oracle/app/grid/19300/cfgtoollogs/opatchauto/core/opatch/opatch2023-03-15_13-56-57PM_1.log

Patch: /oracle/software/parche_octubre22/34416665/34580338
Log: /oracle/app/grid/19300/cfgtoollogs/opatchauto/core/opatch/opatch2023-03-15_13-56-57PM_1.log

OPatchauto session completed at Wed Abr 05 14:05:45 2023
Time taken to complete the session 12 minutes, 51 seconds

¡Epa! Terminado. Si volvemos a comprobar el nivel de parches con lspatches, veremos los nuevos parches instalados:

[oracle@bdstby1 OPatch]$ ./opatch lspatches
34580338;TOMCAT RELEASE UPDATE 19.0.0.0.0 (34580338)
34444834;OCW RELEASE UPDATE 19.17.0.0.0 (34444834)
34428761;ACFS RELEASE UPDATE 19.17.0.0.0 (34428761)
34419443;Database Release Update : 19.17.0.0.221018 (34419443)
33575402;DBWLM RELEASE UPDATE 19.0.0.0.0 (33575402)

OPatch succeeded.

Ahí están todos los parches, aplicaditos en el GRID. Continuamos.

Aplicar OPatch y parcheo de la base de datos

Seguimos para bingo. Nos toca ahora parchear la base de datos, por lo que ya dejamos atrás al usuario root y nos logamos con el usuario propietario de las mismas. Fíjate que antes, cuando el GRID, he usado el usuario oracle para lanzar las comprobaciones de OPatch. Veamos ahora el nivel de parcheo y la versión actual de OPatch para la base de datos, cargando el profile de base de datos en lugar del GRID.

[oracle@bdstby1 ~]$ . ./.profile_BBDD
[oracle@bdstby1 ~]$ cd $ORACLE_HOME/OPatch
[oracle@bdstby1 OPatch]$ ./opatch version
OPatch Version: 12.2.0.1.28

[oracle@bdstby1 OPatch]$ ./opatch lspatches
31281355;Database Release Update : 19.8.0.0.200714 (31281355)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)

Bien, misma tarea que antes: nos vamos a ORACLE_HOME, borramos el OPatch_old, renombramos el OPatch actual a old, descomprimimos el nuevo y, de paso, volvemos a comprobar la versión de OPatch para ver que ya está correctamente instalada la que hemos descargado.

[oracle@bdstby1 OPatch]$ cd ..
[oracle@bdstby1 19300]$ rm -rf OPatch_old
[oracle@bdstby1 19300]$ mv OPatch OPatch_old
[oracle@bdstby1 19300]$ cp /oracle/software/parche_octubre22/p6880880_190000_Linux-x86-64.zip /oracle/app/db/19300
[oracle@bdstby1 19300]$ unzip -d /oracle/app/db/19300 p6880880_190000_Linux-x86-64.zip
[oracle@bdstby1 19300]$ cd OPatch
[oracle@bdstby1 OPatch]$ ./opatch version
OPatch Version: 12.2.0.1.35

Continuamos para parchear la base de datos. Si recordamos el cuadro que adjunté arriba, tenemos que aplicar los subpatches 34419443 y 34444834. Vámonos a la ruta del primero y lanzamos el comando opatch apply.

[oracle@bdstby1 OPatch]$ cd /oracle/software/parche_octubre22/34416665/34419443 
[oracle@bdstby1 34419443]$ /oracle/app/db/19300/OPatch/opatch apply

Installer de Parche Temporal de Oracle versión 12.2.0.1.35
Copyright (c) 2023, Oracle Corporation. Todos los Derechos Reservados.


Directorio raíz de Oracle       : /oracle/app/db/19300
Inventario central: /oracle/app/oraInventory
   de           : /oracle/app/db/19300/oraInst.loc
Versión de OPatch    : 12.2.0.1.35
Versión de OUI       : 12.2.0.7.0
Ubicación del archivo log : /oracle/app/db/19300/cfgtoollogs/opatch/opatch2023-04-05_17-06-38PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   34419443  

¿Desea continuar? [y|n]
y
User Responded with: Y
All checks passed.

Cierre las instancias Oracle que se estén ejecutando fuera de este ORACLE_HOME en el sistema local.
(Directorio Raíz de Oracle = '/oracle/app/db/19300')


¿Está el sistema local listo para aplicarle un parche? [y|n]
y
User Responded with: Y
Backing up files...
Aplicando el parche temporal '34419443' al directorio raíz de Oracle '/oracle/app/db/19300'
ApplySession: Los componentes opcionales [ oracle.network.gsm, 19.0.0.0.0 ] , [ oracle.rdbms.ic, 19.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 19.0.0.0.0 ] , [ oracle.tfa, 19.0.0.0.0 ] , [ oracle.options.olap.api, 19.0.0.0.0 ] , [ oracle.sdo.companion, 19.0.0.0.0 ] , [ oracle.ons.eons.bwcompat, 19.0.0.0.0 ] , [ oracle.rdbms.tg4msql, 19.0.0.0.0 ] , [ oracle.oid.client, 19.0.0.0.0 ] , [ oracle.ons.cclient, 19.0.0.0.0 ] , [ oracle.rdbms.tg4sybs, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.rdbms.tg4tera, 19.0.0.0.0 ] , [ oracle.rdbms.tg4ifmx, 19.0.0.0.0 ] , [ oracle.xdk.companion, 19.0.0.0.0 ] , [ oracle.jdk, 1.8.0.191.0 ]  no están presentes en el directorio raíz de Oracle o se ha encontrado una versión posterior.

Aplicando parche a componente oracle.ordim.jai, 19.0.0.0.0...

Aplicando parche a componente oracle.bali.jewt, 11.1.1.6.0...

Aplicando parche a componente oracle.bali.ewt, 11.1.1.6.0...

Aplicando parche a componente oracle.help.ohj, 11.1.1.7.0...

Aplicando parche a componente oracle.perlint, 5.28.1.0.0...

Aplicando parche a componente oracle.rdbms.locator, 19.0.0.0.0...

Aplicando parche a componente oracle.perlint.expat, 2.0.1.0.4...

Aplicando parche a componente oracle.rdbms.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.util, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms, 19.0.0.0.0...

Aplicando parche a componente oracle.assistants.acf, 19.0.0.0.0...

Aplicando parche a componente oracle.assistants.deconfig, 19.0.0.0.0...

Aplicando parche a componente oracle.assistants.server, 19.0.0.0.0...

Aplicando parche a componente oracle.blaslapack, 19.0.0.0.0...

Aplicando parche a componente oracle.buildtools.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.ctx, 19.0.0.0.0...

Aplicando parche a componente oracle.dbdev, 19.0.0.0.0...

Aplicando parche a componente oracle.dbjava.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.dbjava.jdbc, 19.0.0.0.0...

Aplicando parche a componente oracle.dbjava.ucp, 19.0.0.0.0...

Aplicando parche a componente oracle.duma, 19.0.0.0.0...

Aplicando parche a componente oracle.javavm.client, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.owm, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.security.osdt, 19.0.0.0.0...

Aplicando parche a componente oracle.marvel, 19.0.0.0.0...

Aplicando parche a componente oracle.network.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.odbc.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.ons, 19.0.0.0.0...

Aplicando parche a componente oracle.ons.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.oracore.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.precomp.common.core, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.crs, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.dbscripts, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.deconfig, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.oci, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.rsf.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.rhp.db, 19.0.0.0.0...

Aplicando parche a componente oracle.sdo, 19.0.0.0.0...

Aplicando parche a componente oracle.sdo.locator.jrf, 19.0.0.0.0...

Aplicando parche a componente oracle.sqlplus, 19.0.0.0.0...

Aplicando parche a componente oracle.sqlplus.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.wwg.plsql, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.ssl, 19.0.0.0.0...

Aplicando parche a componente oracle.network.client, 19.0.0.0.0...

Aplicando parche a componente oracle.xdk, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.rsf.ic, 19.0.0.0.0...

Aplicando parche a componente oracle.ldap.client, 19.0.0.0.0...

Aplicando parche a componente oracle.nlsrtl.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.install.common, 19.0.0.0.0...

Aplicando parche a componente oracle.oraolap.dbscripts, 19.0.0.0.0...

Aplicando parche a componente oracle.oraolap.api, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.scheduler, 19.0.0.0.0...

Aplicando parche a componente oracle.mgw.common, 19.0.0.0.0...

Aplicando parche a componente oracle.ctx.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.precomp.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.ctx.atg, 19.0.0.0.0...

Aplicando parche a componente oracle.sdo.locator, 19.0.0.0.0...

Aplicando parche a componente oracle.xdk.xquery, 19.0.0.0.0...

Aplicando parche a componente oracle.xdk.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.xdk.parser.java, 19.0.0.0.0...

Aplicando parche a componente oracle.install.deinstalltool, 19.0.0.0.0...

Aplicando parche a componente oracle.javavm.server, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.hs_common, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.drdaas, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.dv, 19.0.0.0.0...

Aplicando parche a componente oracle.dbtoolslistener, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.rman, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.hsodbc, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.lbac, 19.0.0.0.0...

Aplicando parche a componente oracle.rdbms.install.plugins, 19.0.0.0.0...

Aplicando parche a componente oracle.oraolap, 19.0.0.0.0...

Aplicando parche a componente oracle.network.listener, 19.0.0.0.0...

Aplicando parche a componente oracle.odbc, 19.0.0.0.0...

Aplicando parche a componente oracle.ovm, 19.0.0.0.0...

Aplicando parche a componente oracle.precomp.common, 19.0.0.0.0...

Aplicando parche a componente oracle.precomp.lang, 19.0.0.0.0...

Aplicando parche a componente oracle.jdk, 1.8.0.201.0...
Patch 34419443 successfully applied.
Sub-set patch [33192793] has become inactive due to the application of a super-set patch [34419443].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /oracle/app/db/19300/cfgtoollogs/opatch/opatch2023-04-05_17-06-38PM_1.log

OPatch succeeded.

Primer parche aplicado. Fíjate como el apply te pregunta por dos veces si el sistema está listo para el parcheo (instancias paradas, listener abajo, etc). Vamos con el segundo.

[oracle@bdstby1 34419443]$ cd ../34444834
[oracle@bdstby1 34444834]$ /oracle/app/db/19300/OPatch/opatch apply

Installer de Parche Temporal de Oracle versión 12.2.0.1.35
Copyright (c) 2023, Oracle Corporation. Todos los Derechos Reservados.


Directorio raíz de Oracle       : /oracle/app/db/19300
Inventario central: /oracle/app/oraInventory
   de           : /oracle/app/db/19300/oraInst.loc
Versión de OPatch    : 12.2.0.1.35
Versión de OUI       : 12.2.0.7.0
Ubicación del archivo log : /oracle/app/db/19300/cfgtoollogs/opatch/opatch2023-04-05_17-11-07PM_1.log

Verifying environment and performing prerequisite checks...

--------------------------------------------------------------------------------
Start OOP by Prereq process.
Launch OOP...

Installer de Parche Temporal de Oracle versión 12.2.0.1.35
Copyright (c) 2023, Oracle Corporation. Todos los Derechos Reservados.


Directorio raíz de Oracle       : /oracle/app/db/19300
Inventario central: /oracle/app/oraInventory
   de           : /oracle/app/db/19300/oraInst.loc
Versión de OPatch    : 12.2.0.1.35
Versión de OUI       : 12.2.0.7.0
Ubicación del archivo log : /oracle/app/db/19300/cfgtoollogs/opatch/opatch2023-04-05_17-11-36PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   34444834  

¿Desea continuar? [y|n]
y
User Responded with: Y
All checks passed.

Cierre las instancias Oracle que se estén ejecutando fuera de este ORACLE_HOME en el sistema local.
(Directorio Raíz de Oracle = '/oracle/app/db/19300')


¿Está el sistema local listo para aplicarle un parche? [y|n]
y
User Responded with: Y
Backing up files...
Aplicando el parche temporal '34444834' al directorio raíz de Oracle '/oracle/app/db/19300'
ApplySession: Los componentes opcionales [ oracle.has.crs, 19.0.0.0.0 ] , [ oracle.has.cvu, 19.0.0.0.0 ] , [ oracle.xag, 19.0.0.0.0 ] , [ oracle.rhp.crs, 19.0.0.0.0 ] , [ oracle.has.crs.cvu, 19.0.0.0.0 ]  no están presentes en el directorio raíz de Oracle o se ha encontrado una versión posterior.

Aplicando parche a componente oracle.rdbms, 19.0.0.0.0...

Aplicando parche a componente oracle.has.common, 19.0.0.0.0...

Aplicando parche a componente oracle.has.rsf, 19.0.0.0.0...

Aplicando parche a componente oracle.has.db, 19.0.0.0.0...

Aplicando parche a componente oracle.rhp.common, 19.0.0.0.0...

Aplicando parche a componente oracle.has.common.cvu, 19.0.0.0.0...

Aplicando parche a componente oracle.has.db.cvu, 19.0.0.0.0...

Aplicando parche a componente oracle.rhp.db, 19.0.0.0.0...
Patch 34444834 successfully applied.
Sub-set patch [33208123] has become inactive due to the application of a super-set patch [34444834].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /oracle/app/db/19300/cfgtoollogs/opatch/opatch2023-04-05_17-11-36PM_1.log

OPatch succeeded.

Y otro parche listo. Comprobemos ahora el nivel de parcheo actual.

[oracle@bdstby1 34444834]$ /oracle/app/db/19300/OPatch/opatch lspatches
34444834;OCW RELEASE UPDATE 19.17.0.0.0 (34444834)
34419443;Database Release Update : 19.17.0.0.221018 (34419443)

OPatch succeeded.

¡Et voilà! Bases de datos también parcheadas.

Ahora tocaría realizar todo el apartado 4 y sus subapartados en el otro nodo del entorno (bdstby2) siguiendo el mismo orden: aplicar nuevo OPatch del GRID, parchear el GRID con opatchauto, aplicar nuevo OPatch de la base de datos y parchear la base datos.

Pasos posteriores

IMPORTANTE: no realizar estos pasos sin haber aplicado los parches en todos los nodos del entorno

Vale, ahora que todos nuestros nodos del entorno de emergencias están parcheados, podemos proceder con las tareas posteriores. Estas tareas no son más que levantar listeners e instancias de bases de datos y reactivar la aplicación de redos.

[oracle@bdstby1 ~]$ srvctl status database -d bbdd_emer
Instance BBDD1 is not running on node bdprin1
Instance BBDD2 is not running on node bdprin2

Arrancamos la base de datos y listener.

[oracle@bdstby1 ~]$ srvctl start database -d bbdd_emer
[oracle@bdstby1 ~]$ srvctl status database -d bbdd_emer
Instance BBDD1 is running on node bdprin1
Instance BBDD2 is running on node bdprin2
[oracle@bdstby1 ~]$ srvctl start listener -l LISTENER
[oracle@bdstby1 ~]$ srvctl start listener -l LISTENER_DG

Reactivamos redos:

DGMGRL> show database bbdd_emer

Database - bbdd_emer

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-OFF
  Transport Lag:      0 seconds (computed 0 seconds ago)
  Apply Lag:          (unknown)
  Average Apply Rate: (unknown)
  Real Time Query:    OFF
  Instance(s):
    BBDD1 (apply instance)
    BBDD2

Database Status:
SUCCESS

DGMGRL> edit database bbdd_emer set state='APPLY-ON';
Succeeded.

DGMGRL> exit

Y con esto, damos por finalizado el parcheo en el entorno de emergencias. Recuerda que tal como mencionamos al principio de toda la entrada, ahora tocaría realizar un switchover hacia este entorno para que ejerza como principal, dejando el otro como standby y así poder aplicar los parches.

Una vez aplicado los parches, habría que realizar otro switchover para dejar los entornos normalizados. Pero el switchover no vamos a explicarlo en esta entrada, eso lo haremos en otra.

Compartir entrada en RRSS

SUSCRÍBETE A NUESTRA NEWSLETTER

Si quieres estar al tanto de todas las nuevas publicaciones, suscríbete a esta lista de correo para recibir en tu mail los nuevos posts publicados. ¡Así no te pierdes nada!

pablo_delgado_avatar.jpg

Pablo Delgado Flores

Auténtico apasionado por la informática, especialmente por las bases de datos, administración de sistemas y desarrollo web.

Empecé a trabajar como técnico informático mucho antes de obtener una titulación oficial (sysadmin). Actualmente trabajo como DBA Oracle, aunque manejo otros motores como MySQL/MariaDB, PostgreSQL y Amazon Redshift.

También escribo sobre informática en general en mi web Pablo Delgado Flores, la terminal de Linux/Unix en #Sudosu y  desarrollo web con Woocoomerce/WordPress en DesarrolloWoo.

Subscribirse
Notificar de
guest
0 Comentarios
Comentarios en línea
Ver todos los comentarios