Release Update rolling en Oracle RAC 19c (opatchauto)

Aplica una Release Update trimestral de GI a un cluster RAC 19c de 2–8 nodos en funcionamiento, sin parada (rolling): actualización de OPatch, comprobación de conflictos con opatchauto analyze, backup del OCR y punto de vuelta atrás, aplicación nodo por nodo reubicando los servicios, datapatch completado en un solo nodo, verificación y rollback si es necesario. Para single instance y Oracle Restart utilice la guía "Aplicar una Release Update (RU) de Oracle Database 19c"; la RU de OJVM no es rolling y requiere una parada aparte.

Topología: RAC 19c existente de 2–8 nodos

Antes de empezar

• Se ha leído el README de la RU: versión mínima de OPatch, problemas conocidos, one-offs requeridos, parche OJVM aparte (la RU de OJVM no es rolling y requiere una parada aparte). Se han revisado para esta RU en My Oracle Support "Oracle Database 19c Important Recommended One-off Patches" (Doc ID 555.1) y la guía de descarga de RU (Doc ID 2118136.2).
• En cada nodo están … y p6880880_190000_Linux-x86-64.zip (OPatch actual) bajo …; los ficheros se han verificado con los valores SHA-256 de MOS.
• El sistema de ficheros de los GI y DB homes tiene al menos 20 GB libres (consulte el valor del README) y /tmp al menos 1 GB libre. …… tiene espacio para los backups de los homes.…
• El cluster está sano: CRS online en todos los nodos, ningún recurso en OFFLINE, todas las instancias abiertas. Mientras un nodo está parado durante el parche, los demás tienen capacidad para soportar toda la carga.
• Los servicios de aplicación están definidos de forma que en cada nodo puedan pasar a otra instancia (preferred/available o uniform) y las aplicaciones se conectan mediante SCAN + nombre de servicio (con FAN/AC las sesiones se trasladan sin interrupción).
• La base de datos tiene un backup RMAN actual y sus archived logs; se ha hecho un backup del OCR. La ventana de mantenimiento está aprobada; se ha activado un blackout en Enterprise Manager.
• No hay ninguna otra operación de opatch/opatchauto en curso; no hay ficheros de bloqueo en los homes.
• Si la base de datos tiene un standby de Data Guard, el cluster (o servidor) standby se parchea primero (Standby-First, MOS 1265700.1); el primary se parchea después con esta guía y datapatch se ejecuta solo en el primary.

Fases de la guía

• Comprobaciones previas — Registrar el nivel de parche actual (Clusterware) · Listar los parches de los homes (…) · Registrar el historial de parches SQL y los objetos inválidos
• Preparación: RU, OPatch y análisis — Descomprimir la RU (…) · Actualizar OPatch en el GI home (…) · Actualizar OPatch en el DB home (…) · Ejecutar el análisis de conflictos y requisitos previos (…)
• Backup y punto de vuelta atrás — Hacer un backup manual del OCR · Crear un guaranteed restore point · Hacer backup de los GI y DB homes (…)
• Verificación y cierre — Comprobar que los PDBs están abiertos · Ejecutar datapatch solo en un nodo · Verificar el registro de parches SQL · Recompilar los objetos inválidos (si es necesario) · Verificar el estado de parche del cluster · Devolver los servicios a su ubicación preferida …
• Rollback (solo si es necesario) — Rollback: ejecutar opatchauto rollback (…) · Rollback: ejecutar datapatch (un solo nodo) · Rollback: verificar el resultado · Último recurso: hacer flashback de la base de datos al restore point