ADG真正启用需同时满足：database_role为PHYSICAL STANDBY、open_mode为READ ONLY WITH APPLY、recovery_mode为MANAGED REAL TIME APPLY；常见错误是仅执行ALTER DATABASE OPEN READ ONLY而未启动或维持MRP0进程。
查备库的 open_mode 和 recovery_mode 是否匹配 ADG 要求
很多“ADG 没生效”的问题，其实根本没进入实时应用流程——备库还卡在只读挂起状态。别急着查延迟，先连备库执行：
SELECT database_role, open_mode, recovery_mode FROM v$database, v$archive_dest_status WHERE dest_id = 2;
必须同时满足三项才算真正启用 ADG：
-
database_role是PHYSICAL STANDBY -
open_mode是READ ONLY WITH APPLY（不是READ ONLY） -
recovery_mode是MANAGED REAL TIME APPLY（不是MANAGED STANDBY或空值）
常见错误是只执行了 ALTER DATABASE OPEN READ ONLY，却漏掉启动 MRP 进程；或者 MRP 启动后因 SRL 不足、磁盘满等原因被自动中断。确认 V$MANAGED_STANDBY 中 PROCESS = 'MRP0' 且 STATUS = 'APPLYING_LOG'。
看 transport lag 和 apply lag 的数值与趋势
这两个指标必须在主库查 V$DATAGUARD_STATS，备库查不到；它们不是并列关系，而是因果链：
-
transport lag > 0且apply lag = 0→ 日志还没传到备库，问题出在主库端或网络：TNS不通、LOG_ARCHIVE_DEST_2的ERROR字段有报错、归档路径不可写 -
transport lag = 0但apply lag > 0→ 日志已到备库但应用慢，重点检查：STANDBY_REDO_LOG组数/大小是否足够、MRP0是否被阻塞（查V$SESSION_EVENT等待事件）、I/O 压力是否过高 - 两者都持续增大 → 很可能是归档堆积导致
DB_RECOVERY_FILE_DEST空间耗尽，先查V$RECOVERY_FILE_DEST.SPACE_USED / SPACE_LIMIT是否 ≥ 95%
注意：apply lag 显示 +00 00:00:00 不代表零延迟，只是 Oracle 当前估算无显著滞后；它依赖 STATISTICS_LEVEL = TYPICAL，否则该视图为空。
验证实时应用是否真在用 STANDBY REDO LOG
ASYNC 传输 + Real-Time Apply 完全可行，但前提是备库有可用的 STANDBY REDO LOG（SRL）。没有 SRL，日志只能等主库归档完成后再应用，必然出现秒级甚至分钟级延迟。
在备库执行：
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;
关键点：
- 结果不能为空；否则需手动添加：
ALTER DATABASE ADD STANDBY LOGFILE GROUP n ('/path/to/srl01.log') SIZE 1024M; - 至少有一组状态为
ACTIVE或UNASSIGNED；若全是UNUSED，说明 RFS 进程没把日志写进去 - SRL 大小建议 ≥ Online Redo Log，组数建议 ≥ Online Redo Log 组数 + 1
如果 SRL 存在但不被使用，再查 V$ARCHIVE_DEST_STATUS 的 gap_status：若为 RESOLVABLE GAP 或 UNRESOLVABLE GAP，说明归档传输已断，SRL 再多也没用。
用 DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 测真实延迟
V$DATAGUARD_STATS 的 apply lag 是估算值，有时滞后严重或不准。要测真实同步延迟，得比对主备 SCN：
在主库执行：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL;
立刻在备库执行相同语句，取差值除以每秒 SCN 增速（通常约 1–3 万/秒），就能算出实际延迟秒数。
这个方法绕过了统计视图的缓存和采样机制，特别适合排查“明明 lag 是 0 却查不到刚插入数据”的问题。但要注意：两次查询间隔必须极短，否则主库 SCN 已跳变，误差会放大。
真正卡住的地方往往不在表面参数，而在 SRL 状态、MRP 进程存活性、或 DB_RECOVERY_FILE_DEST 空间是否静默耗尽——这些点一漏，所有 lag 查询都变成误导。
