Aplicar un Release Update (RU) de Oracle Database 19c

Release Update trimestral para una base de datos 19c de instancia única u Oracle Restart (Grid Infrastructure + ASM): actualización de OPatch, comprobaciones previas de conflictos y espacio, backup del ORACLE_HOME y guaranteed restore point, opatch apply (opatchauto para Oracle Restart), OJVM RU opcional, datapatch, utlrp y verificación. Incluye la vía out-of-place que reduce la interrupción (instalar en un home nuevo y cambiar a él) y los pasos de vuelta atrás (rollback) para cada vía. Si se selecciona RAC, remite a la guía de RAC para la aplicación rolling nodo a nodo.

Topología: 1 servidor (instancia única u Oracle Restart); para RAC, la guía de rolling patch

Antes de empezar

• Archivos de parche en …: …GI RU ……DB RU ………, OJVM RU ……, OPatch …… y el archivo de instalación base para el home nuevo, LINUX.X64_193000_db_home.zip…. Compruebe el número de parche en MOS y lea el README del RU de principio a fin (la versión mínima de OPatch, los problemas conocidos y los pasos adicionales figuran en el README).
• Están descargadas las versiones de los parches one-off recomendados en MOS 555.1 que corresponden al RU nuevo; se sabe si los one-offs del home actual entran en conflicto con el RU nuevo (un one-off en conflicto necesita una versión nueva construida sobre el RU).
• El nivel de parches actual y el estado de la base de datos están registrados; todos los componentes están VALID.
• Hay espacio libre de al menos 15 GB en el sistema de archivos del ORACLE_HOME (OPatch guarda los archivos antiguos en .patch_storage), tanto como el tamaño del home en …… y al menos 15 GB para el home nuevo….
• Para el restore point, la base de datos está en modo ARCHIVELOG y la FRA tiene espacio libre suficiente (para los flashback logs generados durante el parcheo).
• Existe un backup RMAN correcto y probado de las últimas 24 horas.
• La ventana de mantenimiento está aprobada; los equipos de aplicaciones conocen la interrupción; la monitorización (EM/agent) está en blackout; los trabajos programados (cron, DBMS_SCHEDULER) están detenidos.
• Si es posible, se ha hecho un snapshot del servidor (VM).
• Si la base de datos tiene un standby de Data Guard, el orden de parcheo está planificado: primero se parchea el home del standby (Standby-First, MOS 1265700.1), después el primary, y datapatch se ejecuta solo en el primary. Si no hay standby, omita este punto.
• El cluster está sano y las instancias están abiertas en todos los nodos; los requisitos previos detallados para parchear RAC están en la guía Release Update rolling de Oracle RAC 19c.
• Condiciones de Standby-First (MOS 1265700.1): el README del RU indica 'Data Guard Standby-First Installable' (los Release Updates cumplen esta condición; para los one-offs consulte su README)…; el OJVM RU de 19c no es Standby-First de forma incondicional (vea la nota más abajo)…; la diferencia de parches entre primary y standby se mantiene solo durante la transición (breve); datapatch se ejecuta una vez, solo en el primary, después de parchear todos los standbys y el primary.… Todos los standbys de este primary tienen instalados los binarios del RU nuevo y siguen con el apply.…

Fases de la guía

• RAC: verificar el entorno y pasar a la guía de rolling patch — Verificar el cluster y los nodos · Aplicar la guía de rolling patch de RAC
• Comprobaciones previas — Comprobar el nivel de parches actual (DB home) · Comprobar el nivel de parches actual (Grid home) · Comprobar el estado de la base de datos y el historial de parches SQL · Comprobar el rol y el estado del apply del standby (standby de Data Guard) · Comprobar el estado de Data Guard (primary) · Verificar que el RU nuevo está instalado en los standbys …
• Backup y punto de vuelta atrás — Comprobar los backups de RMAN · Detener Redo Apply (standby de Data Guard) · Crear un guaranteed restore point · Crear un guaranteed restore point (standby)
• Aplicación: in-place (opatch apply) — Detener la base de datos y el listener · Hacer backup del ORACLE_HOME y del inventario · Aplicar el RU (opatch apply) · Aplicar el OJVM RU · Arrancar el listener y la base de datos · Arrancar el listener y el standby en MOUNT, activar el apply
• Aplicación: in-place (Oracle Restart, opatchauto) — Detener Oracle Restart (para el backup) · Hacer backup del Grid home, del DB home y del inventario · Arrancar Oracle Restart · Aplicar el GI RU (opatchauto) · Aplicar el OJVM RU al DB home · Iniciar Redo Apply (standby de Data Guard)
• Aplicación: out-of-place (home nuevo) — Crear el directorio del home nuevo · Descomprimir el software base y actualizar OPatch · Preparar el response file para el home nuevo · Instalar el home nuevo con el RU · Ejecutar root.sh (home nuevo) · Comparar los parches de los homes antiguo y nuevo …
• Parche a nivel SQL (datapatch) — Ejecutar datapatch · Recompilar los objetos inválidos (utlrp) · No ejecutar datapatch en el standby · Verificar que los cambios SQL llegan a los standbys
• Verificación — Verificar el nivel de parches de los binarios · Verificar el nivel de parches de los binarios (Grid home) · Verificar el registro de parches SQL y los objetos · Verificar en el standby que el apply continúa con los binarios nuevos · Comprobar el alert log · Hacer las pruebas de la aplicación …
• Cierre — Eliminar el restore point · Eliminar el restore point (standby) · Hacer la limpieza
• Vuelta atrás (solo si hace falta) — Detener la base de datos y el listener · Revertir los parches (opatch rollback) · Revertir los parches (opatchauto rollback) · Volver al home antiguo · Arrancar el standby en MOUNT con los binarios antiguos e iniciar el apply · Arrancar y revertir los parches SQL (datapatch) …