Comandos esenciales para administrar Oracle Data Guard

By FrankDatabases, Oracle

Oracle Data Guard es una de las tecnologías más importantes dentro del ecosistema Oracle para implementar alta disponibilidad, protección de datos y recuperación ante desastres.

Si trabajas como DBA, Production Support, SRE o administrador de infraestructura Oracle, conocer los comandos básicos de Data Guard puede ayudarte a determinar rápidamente si existe un problema de redo transport, apply lag, archive logs, Managed Recovery Process o conectividad entre Primary y Standby.

En esta guía veremos algunos de los comandos SQL, Data Guard Broker y comandos de sistema operativo que considero más útiles para operaciones y troubleshooting.

Nota: Los comandos pueden variar dependiendo de la versión de Oracle, arquitectura RAC/Single Instance, configuración de Data Guard y uso o no de Data Guard Broker. Antes de ejecutar operaciones de switchover, failover, reinicio o modificación en producción, valida siempre el procedimiento específico de tu organización.

1. Identificar el rol de la base de datos

Una de las primeras consultas que deberíamos ejecutar es:

SELECT
    name,
    database_role,
    open_mode,
    protection_mode,
    protection_level
FROM v$database;

Podríamos obtener:

NAME      DATABASE_ROLE      OPEN_MODE
--------- ------------------ --------------------
PROD      PRIMARY            READ WRITE

En el Standby podríamos encontrar:

DATABASE_ROLE
----------------
PHYSICAL STANDBY

OPEN_MODE
--------------------
MOUNTED

o, dependiendo de la configuración:

READ ONLY WITH APPLY

Este debería ser uno de los primeros pasos durante troubleshooting:

¿Estoy conectado al Primary o al Standby?

2. Consultar la configuración básica

SELECT
    db_unique_name,
    database_role,
    open_mode,
    switchover_status
FROM v$database;

DB_UNIQUE_NAME es especialmente importante en Data Guard porque permite diferenciar las bases que participan en la configuración.

Por ejemplo:

PROD
PROD_DR

3. Revisar destinos de Archive Log

Una consulta fundamental:

SELECT
    dest_id,
    status,
    destination,
    error
FROM v$archive_dest
WHERE status <> 'INACTIVE';

Esto nos permite detectar errores en los destinos configurados para transportar redo.

También podemos revisar:

SELECT
    dest_id,
    status,
    target,
    destination,
    error
FROM v$archive_dest_status
WHERE status <> 'INACTIVE';

Si existe un problema de transporte, la columna:

ERROR

puede proporcionar una pista muy importante.

4. Revisar parámetros LOG_ARCHIVE_DEST

SHOW PARAMETER log_archive_dest

También:

SHOW PARAMETER log_archive_config

y:

SHOW PARAMETER fal

Esto ayuda a revisar parámetros como:

LOG_ARCHIVE_CONFIG
LOG_ARCHIVE_DEST_1
LOG_ARCHIVE_DEST_2
FAL_SERVER
FAL_CLIENT

La configuración exacta dependerá de la versión y arquitectura utilizada.

5. Forzar un log switch

En el Primary:

ALTER SYSTEM SWITCH LOGFILE;

Otra operación que podemos utilizar durante determinadas verificaciones es:

ALTER SYSTEM ARCHIVE LOG CURRENT;

Esto puede ayudarnos durante pruebas de transporte y aplicación de redo.

No debe utilizarse repetidamente sin motivo en producción.

6. Revisar Archive Logs

SELECT
    thread#,
    sequence#,
    archived,
    status
FROM v$log
ORDER BY thread#, sequence#;

Para revisar archive logs:

SELECT
    thread#,
    sequence#,
    first_time,
    next_time,
    applied
FROM v$archived_log
ORDER BY sequence# DESC
FETCH FIRST 20 ROWS ONLY;

En ambientes RAC debemos prestar atención a:

THREAD#

porque cada instancia puede generar su propio redo thread.

7. Revisar procesos de Data Guard

En el Standby:

SELECT
    process,
    status,
    thread#,
    sequence#
FROM v$managed_standby;

Dependiendo de la versión/configuración podemos encontrar procesos relacionados con:

MRP0
RFS
ARCH

Conceptualmente:

Primary
   ↓
Redo
   ↓
Network
   ↓
RFS
   ↓
Standby Redo Logs
   ↓
MRP
   ↓
Standby Database

En versiones recientes también es importante conocer vistas como V$DATAGUARD_PROCESS.

8. Revisar Data Guard Statistics

Una de las consultas más importantes:

SELECT
    name,
    value,
    unit
FROM v$dataguard_stats;

En un Physical Standby, presta especial atención a:

transport lag
apply lag
apply finish time
estimated startup time

Dos conceptos fundamentales son:

Transport Lag

Indica el retraso relacionado con el transporte de redo desde el Primary hacia el Standby.

Apply Lag

Indica cuánto retraso existe entre el Primary y el redo aplicado en el Standby.

No son exactamente el mismo problema.

9. Revisar Apply Lag

Podemos enfocarnos específicamente en:

SELECT
    name,
    value,
    unit
FROM v$dataguard_stats
WHERE name IN ('transport lag','apply lag');

Ejemplo:

transport lag   +00 00:00:02
apply lag       +00 00:15:30

Esto podría indicar que el redo está llegando al Standby, pero existe retraso en su aplicación.

Esa diferencia es extremadamente importante durante troubleshooting.

10. Revisar Archive Gap

Una consulta muy conocida:

SELECT *
FROM v$archive_gap;

Si no devuelve filas, no significa automáticamente que toda la configuración esté perfecta, pero puede ayudarnos a identificar gaps que Data Guard necesita resolver.

Si existe un gap podríamos encontrar algo similar a:

THREAD#   LOW_SEQUENCE#   HIGH_SEQUENCE#
-------   -------------   --------------
1         10520           10525

11. Comparar último archive recibido y aplicado

En el Standby:

SELECT
    thread#,
    MAX(sequence#) AS last_received
FROM v$archived_log
GROUP BY thread#;

Para revisar el último aplicado:

SELECT
    thread#,
    MAX(sequence#) AS last_applied
FROM v$archived_log
WHERE applied = 'YES'
GROUP BY thread#;

También podemos combinarlos conceptualmente para determinar:

Last Received
      ↓
Last Applied
      ↓
Difference

Si el Standby recibe redo pero no lo aplica, debemos investigar el proceso de recuperación.

12. Iniciar Managed Recovery

En un Physical Standby, dependiendo de versión y configuración:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;

En versiones/configuraciones donde se utiliza Real-Time Apply:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE
DISCONNECT FROM SESSION;

La sintaxis y necesidad de USING CURRENT LOGFILE dependen de la versión de Oracle.

13. Detener Managed Recovery

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Esta operación afecta directamente la aplicación de redo.

En producción no debería ejecutarse simplemente para “probar” si el problema desaparece.

14. Revisar Standby Redo Logs

SELECT
    group#,
    thread#,
    sequence#,
    bytes/1024/1024 AS size_mb,
    status
FROM v$standby_log
ORDER BY thread#, group#;

Los Standby Redo Logs son fundamentales especialmente cuando utilizamos Real-Time Apply.

También debemos verificar que su número y tamaño sean apropiados para la configuración.

15. Revisar Online Redo Logs

SELECT
    group#,
    thread#,
    sequence#,
    bytes/1024/1024 AS size_mb,
    status
FROM v$log
ORDER BY thread#, group#;

Esto es útil para comparar los Online Redo Logs del Primary con los Standby Redo Logs.

16. Revisar errores relacionados con Data Guard

Podemos consultar:

SELECT
    severity,
    error_code,
    message,
    timestamp
FROM v$dataguard_status
ORDER BY timestamp DESC;

Esta vista puede proporcionar información importante sobre eventos y errores relacionados con Data Guard.

17. Revisar el Alert Log

Además de las vistas de Oracle, siempre debemos correlacionar con el Alert Log.

Con ADRCI:

adrci

Después:

show homes

Seleccionar el home correspondiente:

set homepath diag/rdbms/prod/PROD

Consultar alertas:

show alert -tail 100

Seguir el alert log:

show alert -tail -f

Durante problemas de Data Guard podemos encontrar errores relacionados con:

ORA-16xxx
ORA-12xxx
TNS errors
Archive destination errors
Recovery errors
Redo transport errors

18. Verificar conectividad Oracle Net

Desde el servidor correspondiente:

tnsping PROD_DR

También:

tnsping PROD

Pero recuerda:

tnsping no demuestra que la base de datos esté completamente funcional.

Principalmente ayuda a verificar resolución y conectividad Oracle Net hacia el listener.

19. Revisar Listener

lsnrctl status

Servicios registrados:

lsnrctl services

Durante un problema de Data Guard, la conectividad puede involucrar:

Primary
   ↓
Oracle Net
   ↓
DNS
   ↓
Network / Firewall
   ↓
Listener
   ↓
Standby

20. Data Guard Broker

Si la configuración utiliza Data Guard Broker, una de las herramientas principales es:

dgmgrl

Conectar:

DGMGRL> CONNECT /

o según el método de autenticación utilizado.

Mostrar configuración:

DGMGRL> SHOW CONFIGURATION;

Este es uno de los comandos que deberías memorizar.

21. Revisar una base con Broker

DGMGRL> SHOW DATABASE PROD;

Para obtener información más detallada:

DGMGRL> SHOW DATABASE VERBOSE PROD;

Standby:

DGMGRL> SHOW DATABASE VERBOSE PROD_DR;

22. Validar una base

En versiones que soportan esta funcionalidad:

DGMGRL> VALIDATE DATABASE PROD;

Para Standby:

DGMGRL> VALIDATE DATABASE PROD_DR;

Puede proporcionar información muy útil antes de determinadas operaciones de Data Guard.

23. Revisar configuración completa con Broker

DGMGRL> SHOW CONFIGURATION VERBOSE;

Podemos encontrar información relacionada con:

Protection Mode
Members
Primary Database
Physical Standby Database
Configuration Status

Idealmente queremos ver:

SUCCESS

Si encontramos:

WARNING
ERROR

debemos investigar el miembro afectado.

24. Switchover

Con Data Guard Broker:

DGMGRL> SWITCHOVER TO PROD_DR;

Un switchover es un cambio planificado de roles.

Conceptualmente:

ANTES

PROD
PRIMARY
   ↓
PROD_DR
STANDBY


DESPUÉS

PROD
STANDBY
   ↑
PROD_DR
PRIMARY

No debe ejecutarse sin verificar previamente salud, lag, conectividad, readiness y procedimientos de cambio.

25. Failover

Con Broker:

DGMGRL> FAILOVER TO PROD_DR;

Pero aquí debemos hacer una distinción fundamental:

Switchover ≠ Failover

Switchover

Operación planificada donde Primary y Standby intercambian roles.

Failover

Operación utilizada normalmente cuando el Primary no puede continuar prestando servicio.

Un failover puede tener consecuencias importantes para recuperación, reintegración del antiguo Primary y potencial pérdida de datos dependiendo del modo de protección y estado de sincronización.

Nunca debería utilizarse como una simple prueba en producción.

26. Verificar Switchover Status

Desde SQL:

SELECT
    database_role,
    switchover_status
FROM v$database;

Podemos encontrar estados como:

TO STANDBY
TO PRIMARY
SESSIONS ACTIVE
NOT ALLOWED

La interpretación exacta depende del rol y estado de la base.

27. Verificar Force Logging

Para Data Guard es importante revisar:

SELECT
    force_logging
FROM v$database;

Por ejemplo:

FORCE_LOGGING
-------------
YES

28. Flashback Database

Puede ser importante para determinadas estrategias de reintegración:

SELECT
    flashback_on
FROM v$database;

Resultado:

FLASHBACK_ON
------------------
YES

Especialmente cuando se utiliza Broker, Flashback Database puede facilitar ciertos escenarios de reinstatement después de un failover.

29. Revisar procesos desde Linux

Podemos comprobar procesos Oracle:

ps -ef | grep ora_

Por ejemplo:

ps -ef | grep mrp

o:

ps -ef | grep rfs

Sin embargo, las vistas dinámicas de Oracle normalmente proporcionan una visión más confiable del estado lógico de Data Guard.

30. Los comandos que deberías memorizar

Si estás comenzando con Oracle Data Guard, empezaría por estos.

SQL

SELECT database_role, open_mode
FROM v$database;

SELECT *
FROM v$archive_gap;

SELECT name, value, unit
FROM v$dataguard_stats;

SELECT process, status, thread#, sequence#
FROM v$managed_standby;

SELECT dest_id, status, destination, error
FROM v$archive_dest_status
WHERE status <> 'INACTIVE';

SELECT *
FROM v$standby_log;

ALTER SYSTEM SWITCH LOGFILE;

Data Guard Broker

dgmgrl

SHOW CONFIGURATION;

SHOW CONFIGURATION VERBOSE;

SHOW DATABASE PROD;

SHOW DATABASE VERBOSE PROD_DR;

VALIDATE DATABASE PROD_DR;

Sistema operativo

tnsping PROD_DR

lsnrctl status

lsnrctl services

adrci

Metodología de troubleshooting

Supongamos que recibimos una alerta:

“Oracle Standby database is 30 minutes behind Primary.”

No deberíamos comenzar reiniciando Data Guard.

Primero necesitamos determinar:

¿Primary está saludable?
        ↓
DATABASE_ROLE / OPEN_MODE
        ↓
¿Se está generando redo?
        ↓
Redo / Archive Logs
        ↓
¿Redo está siendo transportado?
        ↓
LOG_ARCHIVE_DEST
        ↓
¿Existe Transport Lag?
        ↓
V$DATAGUARD_STATS
        ↓
¿Existe Archive Gap?
        ↓
V$ARCHIVE_GAP
        ↓
¿Redo está llegando al Standby?
        ↓
RFS
        ↓
¿MRP está ejecutándose?
        ↓
Managed Recovery
        ↓
¿Existe Apply Lag?
        ↓
V$DATAGUARD_STATS
        ↓
¿Hay errores?
        ↓
V$DATAGUARD_STATUS / Alert Log
        ↓
Network / Listener
        ↓
Root Cause Analysis

Transport Lag vs Apply Lag

Esta diferencia es fundamental.

Si encontramos:

transport lag = 30 minutes
apply lag     = 30 minutes

podríamos sospechar primero de:

redo transport / network / archive destination / connectivity.

Pero si encontramos:

transport lag = 2 seconds
apply lag     = 30 minutes

el escenario cambia.

El redo está llegando prácticamente a tiempo, pero el Standby no consigue aplicarlo suficientemente rápido.

Ahora investigaríamos aspectos como:

MRP
CPU
I/O
Standby performance
Recovery errors
Redo generation rate
Standby Redo Logs

Esta distinción puede reducir muchísimo el tiempo de diagnóstico.

Una metodología sencilla para recordar

Piensa en Data Guard como una tubería:

PRIMARY
   ↓
Redo Generation
   ↓
Redo Transport
   ↓
Network
   ↓
RFS
   ↓
Standby Redo Logs
   ↓
MRP
   ↓
Redo Apply
   ↓
STANDBY

Cuando Data Guard tiene problemas, la pregunta más importante no es:

“¿Está funcionando Data Guard?”

Una mejor pregunta es:

“¿En qué parte del flujo dejó de avanzar el redo?”

Si identificamos correctamente ese punto, podemos decidir si debemos investigar Primary, transporte, red, listener, RFS, Standby Redo Logs, MRP, I/O o capacidad del Standby.

El objetivo de administrar Data Guard no es solamente mantener un Standby encendido. Es asegurarnos de que, cuando realmente necesitemos utilizarlo, tengamos una copia suficientemente actualizada y operacional para proteger la continuidad del negocio.

¿Qué comando utilizas primero cuando detectas Data Guard lag?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *