V$DATAGUARD_STATS仅主库可查且需STATISTICS_LEVEL=TYPICAL，'apply lag'大小写及空格须精确；apply_lag为INTERVAL类型，需EXTRACT换算秒数；time_computed过旧则数据失效；须结合MRP状态、归档序列号及主备SCN差值验证真实延迟。
查 V$DATAGUARD_STATS 前先确认能否查、查得准不准
这个视图只能在主库查，备库执行会返回空或报 ORA-00942，不是权限问题，是 Oracle 设计如此。它依赖主库对备库状态的主动探测，备库自己不维护该统计。
执行前必须检查 STATISTICS_LEVEL 是否为 TYPICAL（默认满足），否则所有字段全为空；NAME 字段严格区分大小写，必须写成 'apply lag'（带空格），不能写 'apply_lag' 或 'APPLY LAG'。
apply_lag 和 transport_lag 是 INTERVAL DAY TO SECOND 类型，直接 WHERE apply_lag > 60 会报类型错误；正确提取秒数要写：
SELECT EXTRACT(DAY FROM apply_lag) * 86400 + EXTRACT(HOUR FROM apply_lag) * 3600 + EXTRACT(MINUTE FROM apply_lag) * 60 + EXTRACT(SECOND FROM apply_lag) AS apply_lag_seconds FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag';
重点看 time_computed 字段：如果它比当前系统时间晚几分钟，说明该值根本没刷新，apply_lag 再小也没意义。
别只盯 apply lag，必须交叉验证 MRP 状态与归档序列号
V$DATAGUARD_STATS 里的 apply lag 是每 5 秒估算一次的值，不是实时 SCN 同步进度。真正决定查询是否可见的，是备库已应用的 SCN 是否 ≥ 主库事务提交时的 SCN。
- 在备库查
V$MANAGED_STANDBY，确认PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'；若为WAIT_FOR_GAP或WAIT_FOR_LOG，说明日志没收到或卡在归档环节 - 主库查：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DEST_ID = 2（注意：DEST_ID=2才是传给备库的路径） - 备库查：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES'；两者相等才表示归档已完整应用；若APPLIED = 'IN-MEMORY'，说明日志刚收到但尚未刷盘，不算完成
用 SCN 差值代替估算值，算真实延迟秒数
V$DATAGUARD_STATS.apply lag 是 Oracle 根据 SCN 增速反推的估算值，网络抖动、备库负载波动时偏差可达数分钟。真实延迟必须靠主备两端 DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER 直接比对。
操作步骤：
- 主库执行：
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL - 立刻（1 秒内）在备库执行同样语句
- 两 SCN 差值 ÷ 每秒 SCN 增速 ≈ 真实延迟秒数（SCN 增速通常 1~5 万/秒，可参考
V$DATAGUARD_STATS中'estimated startup time'反推） - 如果备库 SCN 长时间不涨，
V$MANAGED_STANDBY里MRP0的PROCESS列可能显示UNKNOWN或DEAD，这时要查alert.log里是否有ORA-16047、ORA-16191等错误
排查三个高频等待事件组合
ADG 备库慢，80% 以上由以下三类等待叠加导致，比调 SQL 优先级更高：
-
log file parallel write：备库写 standby redo 太慢，检查存储 I/O 吞吐、ASM 磁盘组争用、DB_CREATE_FILE_DEST所在磁盘是否满 -
enq: TX - row lock contention：开了 Active Data Guard 但应用还在备库做 DML（比如忘了设READ ONLY），或有未提交事务残留 -
standby query scn wait或read by other session：说明 SCN 没跟上，不是 SQL 问题，是 MRP 进程拖了后腿
真实延迟常藏在这些等待背后，而不是 V$DATAGUARD_STATS 显示的数字里——尤其当 time_computed 过旧、MRP 状态异常、或 SCN 差值持续扩大时，数值再“好看”也得动手查日志和进程。
