systemdba

En la administración de bases de datos Oracle, el proceso de parcheo no termina cuando el binario ha sido actualizado mediante opatch. Un error común en entornos con múltiples instancias (entornos consolidados) es asumir que la ejecución de datapatch en una base de datos actualiza automáticamente a las demás que comparten el mismo Oracle Home.

Recientemente, durante el monitoreo preventivo del Alert Log, identifiqué una serie de advertencias provenientes de Recovery Manager (RMAN) que revelaron una inconsistencia crítica entre el software del servidor y los objetos internos de la base de datos.

El Escenario

El servidor en cuestión aloja cuatro bases de datos bajo el mismo RDBMS. Semanas atrás, se realizó una ventana de mantenimiento para aplicar el Release Update (RU) 19.30.0.0. Sin embargo, al revisar los registros de actividad, se confirmó que el comando datapatch solo se ejecutó en una de las cuatro instancias.

Esta omisión provocó que, aunque el binario de RMAN reportara la versión 19.30, los paquetes internos de la base de datos (como DBMS_BACKUP_RESTORE) permanecieran en la versión 19.27.

El Síntoma: Diagnóstico vía RMAN y SQL

Al conectar RMAN a las bases de datos afectadas, el sistema arrojó el siguiente error de validación:

PL/SQL package SYS.DBMS_BACKUP_RESTORE version 19.27.00.00 in TARGET database is not current
PL/SQL package SYS.DBMS_RCVMAN version 19.27.00.00 in TARGET database is not current

Para validar el estado desde SQLPlus, utilicé la vista dba_registry_sqlpatch, confirmando que el último parche aplicado con éxito en el diccionario de datos seguía siendo el de julio de 2025:

SELECT TO_CHAR(action_time, 'YYYY-MM-DD') AS action_time, 
       action, status, description, patch_id 
FROM sys.dba_registry_sqlpatch 
ORDER BY action_time;

ACTION_TIME  ACTION  STATUS   DESCRIPTION                                 PATCH_ID
-----------  ------  -------  ------------------------------------------  ----------
2021-07-05   APPLY   SUCCESS  Database Release Update : 19.3.0.0.190416   29517242
2023-08-03   APPLY   SUCCESS  Database Release Update : 19.20.0.0.230718  35320081
2024-06-20   APPLY   SUCCESS  Database Release Update : 19.23.0.0.240416  36233263
2025-07-24   APPLY   SUCCESS  Database Release Update : 19.27.0.0.250415  37642901

Paso a Paso: Resolución del Problema

Para corregir esta inconsistencia y asegurar que las funciones de backup y recuperación operen correctamente, es imperativo completar el post-instalación en cada instancia.

• Validación de Inventario: Verificar que el parche esté aplicado correctamente a nivel de binarios:

$ORACLE_HOME/OPatch/opatch lsinventory

• Ejecución de Datapatch: Conectarse a cada una de las bases de datos omitidas y ejecutar la utilidad desde el OS:

cd $ORACLE_HOME/OPatch
./datapatch -verbose

Nota: Datapatch detectará automáticamente los parches pendientes de aplicar en el diccionario de datos.

• Compilación de Objetos (Opcional pero recomendado): En caso de quedar objetos inválidos tras el parcheo:

@?/rdbms/admin/utlrp.sql

• Verificación Final: Ingresar nuevamente a RMAN para confirmar que el mensaje de advertencia haya desaparecido y validar la vista dba_registry_sqlpatch.

La consolidación de bases de datos optimiza recursos, pero incrementa la complejidad de la gestión de parches. Este incidente subraya que cada base de datos es una entidad independiente a nivel de diccionario.

Como DBAs, nuestro checklist de mantenimiento debe garantizar que datapatch se ejecute contra todas las instancias levantadas en el servidor. Ignorar estas alertas de RMAN puede comprometer la integridad de nuestros respaldos y, en última instancia, la capacidad de recuperación ante un desastre.