Oracle Data Guard: operación diaria y escenarios de fallo (19c / 23ai)

Runbook de operación diaria y recuperación ante fallos para una configuración Data Guard (physical standby) ya existente; para la instalación se utiliza la guía de instalación de Data Guard. Si no está seguro de qué hacer, empiece por 'Comprobación de estado y retardo': el diagnóstico de solo lectura le lleva al escenario correcto (switchover planificado, failover, reinstate del antiguo primary, gap de archivado, avance con RECOVER … FROM SERVICE, reconstrucción del standby, snapshot standby, apply/read-only, modo de protección/FSFO/observer, tareas de datafiles y redo logs, backup RMAN desde el standby). Cada escenario sigue el esquema diagnóstico → red de seguridad → ejecución → verificación → tareas posteriores; incluye las vías con broker (DGMGRL) y sin broker (SQL), con las diferencias para instancia única / Oracle Restart / RAC.

Topología: Primary (instancia única / Oracle Restart / RAC) + physical standby (instancia única / Oracle Restart / RAC) + observer opcional

Escenarios

• Comprobación de estado y retardo (¿está todo en orden?) — Solo lectura: configuración, transport/apply lag, gap de archivado, procesos y alert log; no se modifica nada. Si no está seguro de qué hacer, empiece aquí: el último paso le indica el escenario correcto según la salida.
• Switchover planificado (intercambiar los roles) — Primary y standby están sanos y desea intercambiar los roles de forma planificada (mantenimiento, simulacro de DR, devolver los roles); no hay pérdida de datos y la aplicación se interrumpe unos minutos. Mientras pueda acceder al primary, elija siempre esta opción para una transición de roles.
• Primary perdido: failover al standby — No se puede acceder al primary y no va a volver (pérdida del servidor, del almacenamiento o del sitio); el standby pasa a ser el primary. Irreversible: en MaxPerformance pueden perderse los datos de los últimos segundos, y el antiguo primary requiere después un reinstate o una reconstrucción. Si todavía puede acceder al primary, elija switchover.
• Tras un failover, recuperar el antiguo primary como standby (reinstate) — Se ha realizado un failover y el antiguo servidor primary ha vuelto; si Flashback Database está habilitado, se convierte en standby del nuevo primary sin reconstruirlo. El nuevo primary sigue abierto. Si flashback está deshabilitado o la ventana de flashback no es suficiente, el paso de diagnóstico le remite a la reconstrucción.
• Gap de archivado: el standby espera archived logs que faltan — v$archive_gap devuelve filas o el alert log muestra mensajes FAL/gap; el apply está detenido en una secuencia. Las bases de datos siguen abiertas. Si los archived logs que faltan no existen en ningún sitio, una opción del formulario cambia a la vía de avance (roll forward).
• Standby muy retrasado o sin archived logs: avanzarlo (RECOVER FROM SERVICE) — Los archived logs del gap no existen en ningún sitio, operaciones NOLOGGING han dañado el standby o el standby lleva días de retraso; el standby se sincroniza de forma incremental desde el primary sin reconstruirlo (18c+).
• Reconstruir el standby desde cero — No es posible el reinstate (sin flashback) ni el avance, o se han perdido los archivos o el control file del standby; el standby se elimina y se vuelve a crear con DUPLICATE. El primary sigue abierto, pero queda sin protección hasta que termine la reconstrucción (salvo que haya otro standby).
• Convertir en snapshot standby / revertir (copia con escritura para pruebas) — Desea abrir el standby temporalmente en lectura-escritura para hacer pruebas, y después descartar los cambios y volver a physical standby; el primary no se ve afectado y se sigue recibiendo redo, pero mientras sea snapshot standby este standby no está preparado para un failover.
• Detener / iniciar Redo Apply, cambiar la instancia de apply, abrir en read-only — Desea detener o reiniciar MRP por mantenimiento, mover el apply a otra instancia en un standby RAC o abrir el standby para informes (aviso de licencia de Active Data Guard).
• Modo de protección, Fast-Start Failover y observer — Desea cambiar entre MaxPerformance / MaxAvailability / MaxProtection, habilitar o deshabilitar FSFO o gestionar el observer.
• Añadir datafiles, redo logs y standby redo logs / archivo UNNAMED — Hay que añadir un datafile o un redo log en el primary, ha aparecido un archivo UNNAMED en el standby (ORA-01111/ORA-01274) o faltan standby redo logs.
• Hacer un backup RMAN desde el standby — Desea ejecutar los backups RMAN en el standby para descargar al primary de esa carga, y ajustar la política de borrado de archived logs en consecuencia.

Antes de empezar

• En todos los servidores, el perfil del usuario oracle define ORACLE_HOME=…, ORACLE_SID (…en RAC según el nodo …1, …2 …………) y PATH; sqlplus, rman…, dgmgrl… funcionan. La configuración se creó con la guía de instalación de Data Guard o una equivalente (alias TNS …, …, registros estáticos _DGMGRL en el listener, el mismo archivo de contraseñas).
• Se ha verificado que los roles coinciden con los datos introducidos: ahora … es el primary y … es el physical standby. Si no es así (p. ej. porque antes se hizo un switchover), intercambie los nombres en los datos de entrada.
• Se conoce la contraseña de SYS (las transiciones de rol, el reinicio de la instancia remota y RMAN FROM SERVICE necesitan una conexión autenticada con contraseña). La contraseña no contiene @, /, " ni espacios.
• Licencia: Data Guard está incluido en Enterprise Edition. Usar el standby abierto mientras el apply está en marcha, block change tracking en el standby y Far Sync requieren licencia de Active Data Guard. Snapshot standby y la apertura en read-only con el apply detenido no requieren licencia.
• El cambio se realiza en una ventana de mantenimiento aprobada; los equipos de aplicación y de supervisión están informados… (las conexiones se interrumpen unos minutos)….
• La decisión de failover la ha tomado una persona autorizada; está garantizado que el antiguo primary no volverá a abrirse (split-brain): el servidor está apagado, aislado de la red o la instancia se mantiene en MOUNT.

Fases de la guía

• Estado: configuración, retardo y procesos (solo lectura) — Mostrar la configuración del broker y la preparación para la transición de rol · Comprobar el lado primary con SQL · Comprobar el lado standby con SQL · Buscar errores de Data Guard en los alert logs · Interpretar el resultado y elegir el escenario correcto
• 1. Diagnóstico: ¿está preparado para el switchover? — Verificar la preparación (VALIDATE) · Verificar la preparación (SWITCHOVER … VERIFY) · Comprobar el retardo del standby
• 2. Red de seguridad — Guardar la configuración actual (primary) · Guardar la configuración actual (standby)
• 3. Ejecución: switchover — Switchover: convertir … en primary (broker) · Iniciar el switchover (primary → standby) · Abrir el nuevo primary (…) · Actualizar el rol en Clusterware (nuevo primary) · Abrir la otra instancia (nuevo primary nodo …: …) · Montar el antiguo primary como standby (…) …
• 4. Verificación — Verificar los nuevos roles y la configuración · Comprobar el apply y el retardo en el nuevo standby
• 5. Tareas posteriores — Comprobaciones de aplicación, jobs y supervisión
• 1. Diagnóstico: ¿es realmente necesario un failover? — Intentar acceder al primary por última vez (desde el standby) · Evaluar el estado del standby y la posible pérdida de datos · Mostrar el estado tal como lo ve el broker (desde el standby)
• 2. Red de seguridad y redo restante — Guardar los ajustes actuales del standby · Montar el antiguo primary y enviar el redo restante (FLUSH REDO) · Copiar manualmente los archived logs que faltan (sin broker, si es posible)
• 3. Ejecución: failover — Failover: convertir … en primary (broker) · Detener Redo Apply y realizar el failover (SQL) · Abrir el nuevo primary (SQL) · Actualizar el rol en Clusterware (nuevo primary) · Abrir la otra instancia (nuevo primary nodo …: …)
• 4. Verificación — Verificar el nuevo primary
• 5. Tareas posteriores — Hacer un backup completo del nuevo primary · Si vuelve el antiguo primary: NO LO ABRA
• Servicio de aplicación (basado en el rol) — Definir e iniciar el servicio en el lado … (Clusterware) · Definir el servicio en el lado … (Clusterware) · Definir el servicio y el trigger de rol (sin Grid) · Configurar el descriptor de conexión del cliente con dos direcciones
• 1. Diagnóstico: ¿es posible el reinstate? — Comprobar el nuevo primary y el SCN de la transición de rol · Mostrar el estado del broker (nuevo primary) · Montar el antiguo primary y comprobar la ventana de flashback
• 2. Red de seguridad — Guardar el control file y los parámetros del antiguo primary
• 3. Ejecución: reinstate — Hacer el reinstate del antiguo primary (broker) · Arrancar las demás instancias (antiguo primary, RAC) · Flashback y conversión a physical standby (SQL) · Habilitar el destino … en el nuevo primary (SQL) · Iniciar Redo Apply y superar los registros de la transición de rol (SQL)
• 4. Verificación — Verificar la configuración · Verificar el apply en el antiguo primary (nuevo standby)
• 5. Tareas posteriores — Restablecer los roles originales (opcional) y cerrar la causa raíz
• 1. Diagnóstico: ¿dónde está el gap, existen los archived logs? — Mostrar el gap y los procesos en el standby · Comprobar la conexión FAL y el alert log (standby) · ¿Siguen en el primary los archived logs que faltan? · ¿Están en un backup RMAN los archived logs que faltan?
• 2. Red de seguridad — Verificar que hay espacio en la FRA del standby
• 3. Ejecución: traer y registrar los archived logs que faltan — Si los archived logs solo están en un backup: restaurarlos en el primary · Copiar los archived logs que faltan al sistema de archivos y enviarlos al standby (primary) · Registrar los archived logs en el standby · Reiniciar Redo Apply (standby)
• 4. Verificación — Vigilar el cierre del gap (standby)
• 5. Tareas posteriores — Eliminar las copias temporales · Cerrar la causa raíz
• 1. Diagnóstico: ¿cuánto retraso tiene el standby? — Mostrar el SCN y el estado del standby · Comprobar las operaciones NOLOGGING y el valor de COMPATIBLE en el primary
• 2. Red de seguridad — Hacer un backup del control file y del spfile del standby
• 3. Ejecución: avanzar el standby — Detener Redo Apply (standby) · Montar el standby… (solo la instancia 1)… · Avanzar el standby desde el primary (RECOVER STANDBY DATABASE FROM SERVICE) · Arrancar las demás instancias del standby · Comprobar los standby redo logs y el estado de flashback · Iniciar Redo Apply (standby)
• 4. Verificación — Verificar que el retardo se ha cerrado
• 5. Tareas posteriores — Cerrar la causa raíz
• 1. Diagnóstico: ¿es realmente necesaria una reconstrucción? — Mostrar el estado de la configuración y del primary
• 2. Red de seguridad — Conservar los archivos de configuración del standby
• 3. Ejecución: eliminar y reconstruir — Quitar el standby de la configuración del broker · Poner en espera el destino standby en el primary (DEFER) · Eliminar la antigua base de datos standby · Limpiar los archivos restantes del broker, init y contraseñas · Apartar el antiguo archivo init (standby nodo …: …) · Volver a crear el standby con la guía de instalación …