Síntomas comunes
- El monitoreo muestra transport lag o apply lag creciente en V$DATAGUARD_STATS
- SHOW CONFIGURATION en DGMGRL muestra estado Warning o Error
- La standby no tiene los archive logs más recientes de la primaria
- El proceso MRP no aparece en V$MANAGED_STANDBY o muestra estado WAIT_FOR_LOG por mucho tiempo
- Alertas en el alert.log de la standby sobre gaps de secuencia de archivos
- La standby está en modo MOUNT en vez de OPEN READ ONLY
Riesgos para el negocio
- Si la primaria falla con la standby atrasada, se pierde la diferencia de datos entre ellas
- Una standby con lag no puede activarse como nueva primaria con RPO cero
- Un gap de archivos irrecuperable puede requerir un rebuild completo de la standby
- La standby puede no estar disponible para lecturas si hay gaps de recuperación
Checklist técnico detallado
- 1. Verificar el estado de los destinos de archive log en la primaria Si el destino a la standby muestra ERROR o INACTIVE, la primaria no está enviando redo.
- 2. Verificar archivos recibidos pero no aplicados en la standby
- 3. Identificar gaps de secuencia Si faltan secuencias en el rango entre el último aplicado y el actual de la primaria, hay un gap.
- 4. Iniciar el proceso MRP si está detenido
- 5. Detener y reiniciar MRP si está colgado
- 6. Verificar espacio en FRA (Fast Recovery Area) Si la FRA está llena, la standby no puede recibir nuevos archive logs.
- 7. Verificar conectividad de red entre primaria y standby Un problema de red o de servicio de listener puede impedir la llegada de redo.
- 8. Solicitar resolución automática de gap (FAL) Data Guard puede solicitar archivos faltantes automáticamente desde la primaria.
- 9. Revisar el alert.log de la standby por errores específicos
- 10. Verificar modo de protección configurado El modo Maximum Availability o Maximum Protection puede bloquear la primaria si la standby no puede recibir redo.
Cuándo escalar el incidente a un DBA especialista
- Hay un gap de archive logs que la primaria ya no tiene disponibles (archivos purgados de FRA)
- La standby requiere rebuild completo desde la primaria (RMAN DUPLICATE)
- La primaria está en modo Maximum Protection y se ha bloqueado por no poder escribir a la standby
- El lag supera el RPO aprobado y hay un failover planificado próximo
- El alert.log muestra errores de corrupción de bloque en archive logs
Preguntas frecuentes
¿Qué es el proceso MRP en Data Guard?
MRP (Managed Recovery Process) es el proceso que aplica los archivos de redo log recibidos de la primaria en la standby. Si MRP no está corriendo, la standby recibe los archivos pero no los aplica, acumulando lag de aplicación. Se verifica con SELECT process, status FROM V$MANAGED_STANDBY WHERE process LIKE 'MRP%'; y se inicia con ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;.
¿Qué es un gap de archivos en Data Guard?
Un gap ocurre cuando la standby no tiene uno o más archive logs de la secuencia requerida para la recuperación continua. Puede ocurrir por problemas de red, espacio en disco insuficiente en la FRA, o si la standby estuvo desconectada por un período. Data Guard tiene un proceso de resolución automática de gaps (FAL - Fetch Archive Log) que intenta recuperarlos desde la primaria, pero si los archivos ya fueron purgados de la FRA de la primaria, el gap puede requerir un rebuild de la standby.
¿Cuál es la diferencia entre transport lag y apply lag?
El transport lag es el tiempo que tarda el redo generado en la primaria en llegar (transportarse) a la standby. El apply lag es el tiempo adicional que tarda en aplicarse (reproducirse) en la standby una vez recibido. Ambos deben estar cercanos a cero en un Data Guard saludable. Transport lag alto indica un problema de red o de configuración de archivado; apply lag alto indica que MRP está lento, detenido, o la standby tiene presión de I/O.
¿Cuándo usar el modo Synchronous (SYNC) vs Asynchronous (ASYNC)?
SYNC (Maximum Availability o Maximum Protection) garantiza que cada commit en la primaria solo completa cuando el redo ha llegado a la standby. Esto da RPO cero pero puede afectar el rendimiento de la primaria si la red es lenta. ASYNC (Maximum Performance) permite que la primaria confirme sin esperar a la standby, con mejor rendimiento pero con posibilidad de pérdida de datos proporcional al lag. La elección depende del RPO que el negocio puede tolerar.