{"id":1348,"date":"2026-08-20T17:01:58","date_gmt":"2026-08-20T23:01:58","guid":{"rendered":"https:\/\/folken-it.com\/?p=1348"},"modified":"2026-08-21T08:33:56","modified_gmt":"2026-08-21T14:33:56","slug":"comandos-esenciales-para-administrar-oracle-data-guard","status":"publish","type":"post","link":"https:\/\/folken-it.com\/?p=1348","title":{"rendered":"Comandos esenciales para administrar Oracle Data Guard"},"content":{"rendered":"\n

Oracle Data Guard es una de las tecnolog\u00edas m\u00e1s importantes dentro del ecosistema Oracle para implementar alta disponibilidad, protecci\u00f3n de datos y recuperaci\u00f3n ante desastres<\/strong>.<\/p>\n\n\n\n

Si trabajas como DBA, Production Support, SRE o administrador de infraestructura Oracle, conocer los comandos b\u00e1sicos de Data Guard puede ayudarte a determinar r\u00e1pidamente si existe un problema de redo transport, apply lag, archive logs, Managed Recovery Process o conectividad entre Primary y Standby<\/strong>.<\/p>\n\n\n\n

En esta gu\u00eda veremos algunos de los comandos SQL, Data Guard Broker y comandos de sistema operativo que considero m\u00e1s \u00fatiles para operaciones y troubleshooting.<\/p>\n\n\n\n

\n

Nota:<\/strong> Los comandos pueden variar dependiendo de la versi\u00f3n de Oracle, arquitectura RAC\/Single Instance, configuraci\u00f3n de Data Guard y uso o no de Data Guard Broker. Antes de ejecutar operaciones de switchover, failover, reinicio o modificaci\u00f3n en producci\u00f3n, valida siempre el procedimiento espec\u00edfico de tu organizaci\u00f3n.<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

1. Identificar el rol de la base de datos<\/h1>\n\n\n\n

Una de las primeras consultas que deber\u00edamos ejecutar es:<\/p>\n\n\n\n

SELECT\n    name,\n    database_role,\n    open_mode,\n    protection_mode,\n    protection_level\nFROM v$database;<\/code><\/pre>\n\n\n\n
Podr\u00edamos obtener:<\/p>\n\n\n\n
NAME      DATABASE_ROLE      OPEN_MODE\n--------- ------------------ --------------------\nPROD      PRIMARY            READ WRITE<\/code><\/pre>\n\n\n\n
En el Standby podr\u00edamos encontrar:<\/p>\n\n\n\n
DATABASE_ROLE\n----------------\nPHYSICAL STANDBY\n\nOPEN_MODE\n--------------------\nMOUNTED<\/code><\/pre>\n\n\n\n
o, dependiendo de la configuraci\u00f3n:<\/p>\n\n\n\n
READ ONLY WITH APPLY<\/code><\/pre>\n\n\n\n
Este deber\u00eda ser uno de los primeros pasos durante troubleshooting:<\/p>\n\n\n\n
\u00bfEstoy conectado al Primary o al Standby?<\/strong><\/p>\n\n\n\n
\n\n\n\n
2. Consultar la configuraci\u00f3n b\u00e1sica<\/h1>\n\n\n\n
SELECT\n    db_unique_name,\n    database_role,\n    open_mode,\n    switchover_status\nFROM v$database;<\/code><\/pre>\n\n\n\n
DB_UNIQUE_NAME<\/code> es especialmente importante en Data Guard porque permite diferenciar las bases que participan en la configuraci\u00f3n.<\/p>\n\n\n\n
Por ejemplo:<\/p>\n\n\n\n
PROD\nPROD_DR<\/code><\/pre>\n\n\n\n
\n\n\n\n
3. Revisar destinos de Archive Log<\/h1>\n\n\n\n
Una consulta fundamental:<\/p>\n\n\n\n
SELECT\n    dest_id,\n    status,\n    destination,\n    error\nFROM v$archive_dest\nWHERE status <> 'INACTIVE';<\/code><\/pre>\n\n\n\n
Esto nos permite detectar errores en los destinos configurados para transportar redo.<\/p>\n\n\n\n
Tambi\u00e9n podemos revisar:<\/p>\n\n\n\n
SELECT\n    dest_id,\n    status,\n    target,\n    destination,\n    error\nFROM v$archive_dest_status\nWHERE status <> 'INACTIVE';<\/code><\/pre>\n\n\n\n
Si existe un problema de transporte, la columna:<\/p>\n\n\n\n
ERROR<\/code><\/pre>\n\n\n\n
puede proporcionar una pista muy importante.<\/p>\n\n\n\n
\n\n\n\n
4. Revisar par\u00e1metros LOG_ARCHIVE_DEST<\/h1>\n\n\n\n
SHOW PARAMETER log_archive_dest<\/code><\/pre>\n\n\n\n
Tambi\u00e9n:<\/p>\n\n\n\n
SHOW PARAMETER log_archive_config<\/code><\/pre>\n\n\n\n
y:<\/p>\n\n\n\n
SHOW PARAMETER fal<\/code><\/pre>\n\n\n\n
Esto ayuda a revisar par\u00e1metros como:<\/p>\n\n\n\n
LOG_ARCHIVE_CONFIG\nLOG_ARCHIVE_DEST_1\nLOG_ARCHIVE_DEST_2\nFAL_SERVER\nFAL_CLIENT<\/code><\/pre>\n\n\n\n
La configuraci\u00f3n exacta depender\u00e1 de la versi\u00f3n y arquitectura utilizada.<\/p>\n\n\n\n
\n\n\n\n
5. Forzar un log switch<\/h1>\n\n\n\n
En el Primary:<\/p>\n\n\n\n
ALTER SYSTEM SWITCH LOGFILE;<\/code><\/pre>\n\n\n\n
Otra operaci\u00f3n que podemos utilizar durante determinadas verificaciones es:<\/p>\n\n\n\n
ALTER SYSTEM ARCHIVE LOG CURRENT;<\/code><\/pre>\n\n\n\n
Esto puede ayudarnos durante pruebas de transporte y aplicaci\u00f3n de redo.<\/p>\n\n\n\n
No debe utilizarse repetidamente sin motivo en producci\u00f3n.<\/p>\n\n\n\n
\n\n\n\n
6. Revisar Archive Logs<\/h1>\n\n\n\n
SELECT\n    thread#,\n    sequence#,\n    archived,\n    status\nFROM v$log\nORDER BY thread#, sequence#;<\/code><\/pre>\n\n\n\n
Para revisar archive logs:<\/p>\n\n\n\n
SELECT\n    thread#,\n    sequence#,\n    first_time,\n    next_time,\n    applied\nFROM v$archived_log\nORDER BY sequence# DESC\nFETCH FIRST 20 ROWS ONLY;<\/code><\/pre>\n\n\n\n
En ambientes RAC debemos prestar atenci\u00f3n a:<\/p>\n\n\n\n
THREAD#<\/code><\/pre>\n\n\n\n
porque cada instancia puede generar su propio redo thread.<\/p>\n\n\n\n
\n\n\n\n
7. Revisar procesos de Data Guard<\/h1>\n\n\n\n
En el Standby:<\/p>\n\n\n\n
SELECT\n    process,\n    status,\n    thread#,\n    sequence#\nFROM v$managed_standby;<\/code><\/pre>\n\n\n\n
Dependiendo de la versi\u00f3n\/configuraci\u00f3n podemos encontrar procesos relacionados con:<\/p>\n\n\n\n
MRP0\nRFS\nARCH<\/code><\/pre>\n\n\n\n
Conceptualmente:<\/p>\n\n\n\n
Primary\n   \u2193\nRedo\n   \u2193\nNetwork\n   \u2193\nRFS\n   \u2193\nStandby Redo Logs\n   \u2193\nMRP\n   \u2193\nStandby Database<\/code><\/pre>\n\n\n\n
En versiones recientes tambi\u00e9n es importante conocer vistas como V$DATAGUARD_PROCESS<\/code>.<\/p>\n\n\n\n
\n\n\n\n
8. Revisar Data Guard Statistics<\/h1>\n\n\n\n
Una de las consultas m\u00e1s importantes:<\/p>\n\n\n\n
SELECT\n    name,\n    value,\n    unit\nFROM v$dataguard_stats;<\/code><\/pre>\n\n\n\n
En un Physical Standby, presta especial atenci\u00f3n a:<\/p>\n\n\n\n
transport lag\napply lag\napply finish time\nestimated startup time<\/code><\/pre>\n\n\n\n
Dos conceptos fundamentales son:<\/p>\n\n\n\n
Transport Lag<\/h3>\n\n\n\n
Indica el retraso relacionado con el transporte de redo desde el Primary hacia el Standby.<\/p>\n\n\n\n
Apply Lag<\/h3>\n\n\n\n
Indica cu\u00e1nto retraso existe entre el Primary y el redo aplicado en el Standby.<\/p>\n\n\n\n
No son exactamente el mismo problema.<\/p>\n\n\n\n
\n\n\n\n
9. Revisar Apply Lag<\/h1>\n\n\n\n
Podemos enfocarnos espec\u00edficamente en:<\/p>\n\n\n\n
SELECT\n    name,\n    value,\n    unit\nFROM v$dataguard_stats\nWHERE name IN ('transport lag','apply lag');<\/code><\/pre>\n\n\n\n
Ejemplo:<\/p>\n\n\n\n
transport lag   +00 00:00:02\napply lag       +00 00:15:30<\/code><\/pre>\n\n\n\n
Esto podr\u00eda indicar que el redo est\u00e1 llegando al Standby, pero existe retraso en su aplicaci\u00f3n.<\/p>\n\n\n\n
Esa diferencia es extremadamente importante durante troubleshooting.<\/p>\n\n\n\n
\n\n\n\n
10. Revisar Archive Gap<\/h1>\n\n\n\n
Una consulta muy conocida:<\/p>\n\n\n\n
SELECT *\nFROM v$archive_gap;<\/code><\/pre>\n\n\n\n
Si no devuelve filas, no significa autom\u00e1ticamente que toda la configuraci\u00f3n est\u00e9 perfecta, pero puede ayudarnos a identificar gaps que Data Guard necesita resolver.<\/p>\n\n\n\n
Si existe un gap podr\u00edamos encontrar algo similar a:<\/p>\n\n\n\n
THREAD#   LOW_SEQUENCE#   HIGH_SEQUENCE#\n-------   -------------   --------------\n1         10520           10525<\/code><\/pre>\n\n\n\n
\n\n\n\n
11. Comparar \u00faltimo archive recibido y aplicado<\/h1>\n\n\n\n
En el Standby:<\/p>\n\n\n\n
SELECT\n    thread#,\n    MAX(sequence#) AS last_received\nFROM v$archived_log\nGROUP BY thread#;<\/code><\/pre>\n\n\n\n
Para revisar el \u00faltimo aplicado:<\/p>\n\n\n\n
SELECT\n    thread#,\n    MAX(sequence#) AS last_applied\nFROM v$archived_log\nWHERE applied = 'YES'\nGROUP BY thread#;<\/code><\/pre>\n\n\n\n
Tambi\u00e9n podemos combinarlos conceptualmente para determinar:<\/p>\n\n\n\n
Last Received\n      \u2193\nLast Applied\n      \u2193\nDifference<\/code><\/pre>\n\n\n\n
Si el Standby recibe redo pero no lo aplica, debemos investigar el proceso de recuperaci\u00f3n.<\/p>\n\n\n\n
\n\n\n\n
12. Iniciar Managed Recovery<\/h1>\n\n\n\n
En un Physical Standby, dependiendo de versi\u00f3n y configuraci\u00f3n:<\/p>\n\n\n\n
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE\nDISCONNECT FROM SESSION;<\/code><\/pre>\n\n\n\n
En versiones\/configuraciones donde se utiliza Real-Time Apply:<\/p>\n\n\n\n
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE\nUSING CURRENT LOGFILE\nDISCONNECT FROM SESSION;<\/code><\/pre>\n\n\n\n
La sintaxis y necesidad de USING CURRENT LOGFILE<\/code> dependen de la versi\u00f3n de Oracle.<\/p>\n\n\n\n
\n\n\n\n
13. Detener Managed Recovery<\/h1>\n\n\n\n
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;<\/code><\/pre>\n\n\n\n
Esta operaci\u00f3n afecta directamente la aplicaci\u00f3n de redo.<\/p>\n\n\n\n
En producci\u00f3n no deber\u00eda ejecutarse simplemente para “probar” si el problema desaparece.<\/p>\n\n\n\n
\n\n\n\n
14. Revisar Standby Redo Logs<\/h1>\n\n\n\n
SELECT\n    group#,\n    thread#,\n    sequence#,\n    bytes\/1024\/1024 AS size_mb,\n    status\nFROM v$standby_log\nORDER BY thread#, group#;<\/code><\/pre>\n\n\n\n
Los Standby Redo Logs son fundamentales especialmente cuando utilizamos Real-Time Apply.<\/p>\n\n\n\n
Tambi\u00e9n debemos verificar que su n\u00famero y tama\u00f1o sean apropiados para la configuraci\u00f3n.<\/p>\n\n\n\n
\n\n\n\n
15. Revisar Online Redo Logs<\/h1>\n\n\n\n
SELECT\n    group#,\n    thread#,\n    sequence#,\n    bytes\/1024\/1024 AS size_mb,\n    status\nFROM v$log\nORDER BY thread#, group#;<\/code><\/pre>\n\n\n\n
Esto es \u00fatil para comparar los Online Redo Logs del Primary con los Standby Redo Logs.<\/p>\n\n\n\n
\n\n\n\n
16. Revisar errores relacionados con Data Guard<\/h1>\n\n\n\n
Podemos consultar:<\/p>\n\n\n\n
SELECT\n    severity,\n    error_code,\n    message,\n    timestamp\nFROM v$dataguard_status\nORDER BY timestamp DESC;<\/code><\/pre>\n\n\n\n
Esta vista puede proporcionar informaci\u00f3n importante sobre eventos y errores relacionados con Data Guard.<\/p>\n\n\n\n
\n\n\n\n
17. Revisar el Alert Log<\/h1>\n\n\n\n
Adem\u00e1s de las vistas de Oracle, siempre debemos correlacionar con el Alert Log.<\/p>\n\n\n\n
Con ADRCI:<\/p>\n\n\n\n
adrci<\/code><\/pre>\n\n\n\n
Despu\u00e9s:<\/p>\n\n\n\n
show homes<\/code><\/pre>\n\n\n\n
Seleccionar el home correspondiente:<\/p>\n\n\n\n
set homepath diag\/rdbms\/prod\/PROD<\/code><\/pre>\n\n\n\n
Consultar alertas:<\/p>\n\n\n\n
show alert -tail 100<\/code><\/pre>\n\n\n\n
Seguir el alert log:<\/p>\n\n\n\n
show alert -tail -f<\/code><\/pre>\n\n\n\n
Durante problemas de Data Guard podemos encontrar errores relacionados con:<\/p>\n\n\n\n
ORA-16xxx\nORA-12xxx\nTNS errors\nArchive destination errors\nRecovery errors\nRedo transport errors<\/code><\/pre>\n\n\n\n
\n\n\n\n
18. Verificar conectividad Oracle Net<\/h1>\n\n\n\n
Desde el servidor correspondiente:<\/p>\n\n\n\n
tnsping PROD_DR<\/code><\/pre>\n\n\n\n
Tambi\u00e9n:<\/p>\n\n\n\n
tnsping PROD<\/code><\/pre>\n\n\n\n
Pero recuerda:<\/p>\n\n\n\n
tnsping<\/code> no demuestra que la base de datos est\u00e9 completamente funcional.<\/p>\n\n\n\n
Principalmente ayuda a verificar resoluci\u00f3n y conectividad Oracle Net hacia el listener.<\/p>\n\n\n\n
\n\n\n\n
19. Revisar Listener<\/h1>\n\n\n\n
lsnrctl status<\/code><\/pre>\n\n\n\n
Servicios registrados:<\/p>\n\n\n\n
lsnrctl services<\/code><\/pre>\n\n\n\n
Durante un problema de Data Guard, la conectividad puede involucrar:<\/p>\n\n\n\n
Primary\n   \u2193\nOracle Net\n   \u2193\nDNS\n   \u2193\nNetwork \/ Firewall\n   \u2193\nListener\n   \u2193\nStandby<\/code><\/pre>\n\n\n\n
\n\n\n\n
20. Data Guard Broker<\/h1>\n\n\n\n
Si la configuraci\u00f3n utiliza Data Guard Broker, una de las herramientas principales es:<\/p>\n\n\n\n
dgmgrl<\/code><\/pre>\n\n\n\n
Conectar:<\/p>\n\n\n\n
DGMGRL> CONNECT \/<\/code><\/pre>\n\n\n\n
o seg\u00fan el m\u00e9todo de autenticaci\u00f3n utilizado.<\/p>\n\n\n\n
Mostrar configuraci\u00f3n:<\/p>\n\n\n\n
DGMGRL> SHOW CONFIGURATION;<\/code><\/pre>\n\n\n\n
Este es uno de los comandos que deber\u00edas memorizar.<\/p>\n\n\n\n
\n\n\n\n
21. Revisar una base con Broker<\/h1>\n\n\n\n
DGMGRL> SHOW DATABASE PROD;<\/code><\/pre>\n\n\n\n
Para obtener informaci\u00f3n m\u00e1s detallada:<\/p>\n\n\n\n
DGMGRL> SHOW DATABASE VERBOSE PROD;<\/code><\/pre>\n\n\n\n
Standby:<\/p>\n\n\n\n
DGMGRL> SHOW DATABASE VERBOSE PROD_DR;<\/code><\/pre>\n\n\n\n
\n\n\n\n
22. Validar una base<\/h1>\n\n\n\n
En versiones que soportan esta funcionalidad:<\/p>\n\n\n\n
DGMGRL> VALIDATE DATABASE PROD;<\/code><\/pre>\n\n\n\n
Para Standby:<\/p>\n\n\n\n
DGMGRL> VALIDATE DATABASE PROD_DR;<\/code><\/pre>\n\n\n\n
Puede proporcionar informaci\u00f3n muy \u00fatil antes de determinadas operaciones de Data Guard.<\/p>\n\n\n\n
\n\n\n\n
23. Revisar configuraci\u00f3n completa con Broker<\/h1>\n\n\n\n
DGMGRL> SHOW CONFIGURATION VERBOSE;<\/code><\/pre>\n\n\n\n
Podemos encontrar informaci\u00f3n relacionada con:<\/p>\n\n\n\n
Protection Mode\nMembers\nPrimary Database\nPhysical Standby Database\nConfiguration Status<\/code><\/pre>\n\n\n\n
Idealmente queremos ver:<\/p>\n\n\n\n
SUCCESS<\/code><\/pre>\n\n\n\n
Si encontramos:<\/p>\n\n\n\n
WARNING\nERROR<\/code><\/pre>\n\n\n\n
debemos investigar el miembro afectado.<\/p>\n\n\n\n
\n\n\n\n
24. Switchover<\/h1>\n\n\n\n
Con Data Guard Broker:<\/p>\n\n\n\n
DGMGRL> SWITCHOVER TO PROD_DR;<\/code><\/pre>\n\n\n\n
Un switchover<\/strong> es un cambio planificado de roles.<\/p>\n\n\n\n
Conceptualmente:<\/p>\n\n\n\n
ANTES\n\nPROD\nPRIMARY\n   \u2193\nPROD_DR\nSTANDBY\n\n\nDESPU\u00c9S\n\nPROD\nSTANDBY\n   \u2191\nPROD_DR\nPRIMARY<\/code><\/pre>\n\n\n\n
No debe ejecutarse sin verificar previamente salud, lag, conectividad, readiness y procedimientos de cambio.<\/p>\n\n\n\n
\n\n\n\n
25. Failover<\/h1>\n\n\n\n
Con Broker:<\/p>\n\n\n\n
DGMGRL> FAILOVER TO PROD_DR;<\/code><\/pre>\n\n\n\n
Pero aqu\u00ed debemos hacer una distinci\u00f3n fundamental:<\/p>\n\n\n\n
Switchover \u2260 Failover<\/strong><\/p>\n\n\n\n
Switchover<\/h3>\n\n\n\n
Operaci\u00f3n planificada donde Primary y Standby intercambian roles.<\/p>\n\n\n\n
Failover<\/h3>\n\n\n\n
Operaci\u00f3n utilizada normalmente cuando el Primary no puede continuar prestando servicio.<\/p>\n\n\n\n
Un failover puede tener consecuencias importantes para recuperaci\u00f3n, reintegraci\u00f3n del antiguo Primary y potencial p\u00e9rdida de datos dependiendo del modo de protecci\u00f3n y estado de sincronizaci\u00f3n.<\/p>\n\n\n\n
Nunca deber\u00eda utilizarse como una simple prueba en producci\u00f3n.<\/p>\n\n\n\n
\n\n\n\n
26. Verificar Switchover Status<\/h1>\n\n\n\n
Desde SQL:<\/p>\n\n\n\n
SELECT\n    database_role,\n    switchover_status\nFROM v$database;<\/code><\/pre>\n\n\n\n
Podemos encontrar estados como:<\/p>\n\n\n\n
TO STANDBY\nTO PRIMARY\nSESSIONS ACTIVE\nNOT ALLOWED<\/code><\/pre>\n\n\n\n
La interpretaci\u00f3n exacta depende del rol y estado de la base.<\/p>\n\n\n\n
\n\n\n\n
27. Verificar Force Logging<\/h1>\n\n\n\n
Para Data Guard es importante revisar:<\/p>\n\n\n\n
SELECT\n    force_logging\nFROM v$database;<\/code><\/pre>\n\n\n\n
Por ejemplo:<\/p>\n\n\n\n
FORCE_LOGGING\n-------------\nYES<\/code><\/pre>\n\n\n\n
\n\n\n\n
28. Flashback Database<\/h1>\n\n\n\n
Puede ser importante para determinadas estrategias de reintegraci\u00f3n:<\/p>\n\n\n\n
SELECT\n    flashback_on\nFROM v$database;<\/code><\/pre>\n\n\n\n
Resultado:<\/p>\n\n\n\n
FLASHBACK_ON\n------------------\nYES<\/code><\/pre>\n\n\n\n
Especialmente cuando se utiliza Broker, Flashback Database puede facilitar ciertos escenarios de reinstatement despu\u00e9s de un failover.<\/p>\n\n\n\n
\n\n\n\n
29. Revisar procesos desde Linux<\/h1>\n\n\n\n
Podemos comprobar procesos Oracle:<\/p>\n\n\n\n
ps -ef | grep ora_<\/code><\/pre>\n\n\n\n
Por ejemplo:<\/p>\n\n\n\n
ps -ef | grep mrp<\/code><\/pre>\n\n\n\n
o:<\/p>\n\n\n\n
ps -ef | grep rfs<\/code><\/pre>\n\n\n\n
Sin embargo, las vistas din\u00e1micas de Oracle normalmente proporcionan una visi\u00f3n m\u00e1s confiable del estado l\u00f3gico de Data Guard.<\/p>\n\n\n\n
\n\n\n\n
30. Los comandos que deber\u00edas memorizar<\/h1>\n\n\n\n
Si est\u00e1s comenzando con Oracle Data Guard, empezar\u00eda por estos.<\/p>\n\n\n\n
SQL<\/h3>\n\n\n\n
SELECT database_role, open_mode\nFROM v$database;\n\nSELECT *\nFROM v$archive_gap;\n\nSELECT name, value, unit\nFROM v$dataguard_stats;\n\nSELECT process, status, thread#, sequence#\nFROM v$managed_standby;\n\nSELECT dest_id, status, destination, error\nFROM v$archive_dest_status\nWHERE status <> 'INACTIVE';\n\nSELECT *\nFROM v$standby_log;\n\nALTER SYSTEM SWITCH LOGFILE;<\/code><\/pre>\n\n\n\n
Data Guard Broker<\/h3>\n\n\n\n
dgmgrl\n\nSHOW CONFIGURATION;\n\nSHOW CONFIGURATION VERBOSE;\n\nSHOW DATABASE PROD;\n\nSHOW DATABASE VERBOSE PROD_DR;\n\nVALIDATE DATABASE PROD_DR;<\/code><\/pre>\n\n\n\n
Sistema operativo<\/h3>\n\n\n\n
tnsping PROD_DR\n\nlsnrctl status\n\nlsnrctl services\n\nadrci<\/code><\/pre>\n\n\n\n
\n\n\n\n
Metodolog\u00eda de troubleshooting<\/h1>\n\n\n\n
Supongamos que recibimos una alerta:<\/p>\n\n\n\n
“Oracle Standby database is 30 minutes behind Primary.”<\/strong><\/p>\n\n\n\n
No deber\u00edamos comenzar reiniciando Data Guard.<\/p>\n\n\n\n
Primero necesitamos determinar:<\/p>\n\n\n\n
\u00bfPrimary est\u00e1 saludable?\n        \u2193\nDATABASE_ROLE \/ OPEN_MODE\n        \u2193\n\u00bfSe est\u00e1 generando redo?\n        \u2193\nRedo \/ Archive Logs\n        \u2193\n\u00bfRedo est\u00e1 siendo transportado?\n        \u2193\nLOG_ARCHIVE_DEST\n        \u2193\n\u00bfExiste Transport Lag?\n        \u2193\nV$DATAGUARD_STATS\n        \u2193\n\u00bfExiste Archive Gap?\n        \u2193\nV$ARCHIVE_GAP\n        \u2193\n\u00bfRedo est\u00e1 llegando al Standby?\n        \u2193\nRFS\n        \u2193\n\u00bfMRP est\u00e1 ejecut\u00e1ndose?\n        \u2193\nManaged Recovery\n        \u2193\n\u00bfExiste Apply Lag?\n        \u2193\nV$DATAGUARD_STATS\n        \u2193\n\u00bfHay errores?\n        \u2193\nV$DATAGUARD_STATUS \/ Alert Log\n        \u2193\nNetwork \/ Listener\n        \u2193\nRoot Cause Analysis<\/code><\/pre>\n\n\n\n
\n\n\n\n
Transport Lag vs Apply Lag<\/h1>\n\n\n\n
Esta diferencia es fundamental.<\/p>\n\n\n\n
Si encontramos:<\/p>\n\n\n\n
transport lag = 30 minutes\napply lag     = 30 minutes<\/code><\/pre>\n\n\n\n
podr\u00edamos sospechar primero de:<\/p>\n\n\n\n
redo transport \/ network \/ archive destination \/ connectivity.<\/strong><\/p>\n\n\n\n
Pero si encontramos:<\/p>\n\n\n\n
transport lag = 2 seconds\napply lag     = 30 minutes<\/code><\/pre>\n\n\n\n
el escenario cambia.<\/p>\n\n\n\n
El redo est\u00e1 llegando pr\u00e1cticamente a tiempo, pero el Standby no consigue aplicarlo suficientemente r\u00e1pido.<\/p>\n\n\n\n
Ahora investigar\u00edamos aspectos como:<\/p>\n\n\n\n
MRP\nCPU\nI\/O\nStandby performance\nRecovery errors\nRedo generation rate\nStandby Redo Logs<\/code><\/pre>\n\n\n\n
Esta distinci\u00f3n puede reducir much\u00edsimo el tiempo de diagn\u00f3stico.<\/p>\n\n\n\n
\n\n\n\n
Una metodolog\u00eda sencilla para recordar<\/h1>\n\n\n\n
Piensa en Data Guard como una tuber\u00eda:<\/p>\n\n\n\n
PRIMARY\n   \u2193\nRedo Generation\n   \u2193\nRedo Transport\n   \u2193\nNetwork\n   \u2193\nRFS\n   \u2193\nStandby Redo Logs\n   \u2193\nMRP\n   \u2193\nRedo Apply\n   \u2193\nSTANDBY<\/code><\/pre>\n\n\n\n
Cuando Data Guard tiene problemas, la pregunta m\u00e1s importante no es:<\/p>\n\n\n\n
\n
“\u00bfEst\u00e1 funcionando Data Guard?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Una mejor pregunta es:<\/p>\n\n\n\n
\n
“\u00bfEn qu\u00e9 parte del flujo dej\u00f3 de avanzar el redo?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
\u00bfQu\u00e9 comando utilizas primero cuando detectas Data Guard lag?<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
Oracle Data Guard es una de las tecnolog\u00edas m\u00e1s importantes dentro del ecosistema Oracle para implementar alta disponibilidad, protecci\u00f3n de datos y […]<\/p>\n","protected":false},"author":2,"featured_media":1349,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[56,55],"tags":[],"class_list":["post-1348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-databases","category-oracle"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/08\/dataguard.png?fit=1536%2C1024&ssl=1","_links":{"self":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1348","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1348"}],"version-history":[{"count":1,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1348\/revisions"}],"predecessor-version":[{"id":1350,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1348\/revisions\/1350"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/media\/1349"}],"wp:attachment":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1348"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1348"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1348"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}