必须在主库查v$dataguard_stats，因该视图仅主库存在且依赖其主动探测；备库执行会报ora-00942或返回空；apply lag和transport lag为interval类型，须用extract提取秒数；延迟为0不等于实时同步，需交叉验证current_scn与applied_scn差值。
必须在主库查 V$DATAGUARD_STATS，备库查不到真实延迟值
AWR 本身不直接采集 Data Guard 延迟数据，V$DATAGUARD_STATS 是唯一能拿到 transport lag 和 apply lag 的实时视图，但它只在主库内存中存在。你在备库执行 SELECT * FROM V$DATAGUARD_STATS，要么报 ORA-00942: table or view does not exist，要么返回空行——这不是权限或脚本写错，而是 Oracle 内部设计：该视图依赖主库主动探测备库状态并聚合计算，备库根本没有这个结构。
常见误操作包括：
- 在备库反复重试该查询，怀疑监控脚本失效
- 用 OEM 或第三方工具连备库取该视图，结果始终为空，误判为“延迟监控断了”
- 把
V$DATAGUARD_STATS当成跨库通用视图，写进统一巡检脚本却未做主备路由判断
从 AWR 报告里定位延迟瓶颈，得盯紧三个关联视图
虽然 AWR 不存 transport lag，但能交叉验证延迟是否已影响 I/O 和应用行为。关键不是单看一个数字，而是组合分析：
-
V$MANAGED_STANDBY：查 MRP 进程状态。如果PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'才是正常；若为WAIT_FOR_LOG或RECOVERING卡住，说明日志没传到或应用卡死 -
V$ARCHIVE_DEST_STATUS：重点看DEST_ID = 2（对应物理备库）的STATUS、ERROR、TRANSMIT_MODE和APPLIED_SCN。若APPLIED_SCN长期不更新，或ERROR列有内容，就是实际同步断点 -
V$ARCHIVED_LOG：对比主备的SEQUENCE#和FIRST_TIME。在主库查MAX(SEQUENCE#)，再在备库查同线程下最大已接收/已应用序号，差值超过 2–3 就值得人工介入
apply lag 显示 0 不代表实时，必须比对 SCN 差值
V$DATAGUARD_STATS 中的 apply lag 是基于日志头时间戳与系统时钟差估算的，不是真实数据可见性指标。即使它显示 +00 00:00:00，应用仍可能查不到主库刚提交的数据。
真正决定“能不能读到”的，是备库当前已应用的 SCN 是否 ≥ 主库事务提交时的 SCN。所以必须交叉验证：
- 主库执行：
SELECT CURRENT_SCN FROM V$DATABASE - 备库执行：
SELECT APPLIED_SCN FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 1（或查V$DATAGUARD_STATS中NAME = 'latest applied scn'的VALUE） - 两者的差值才是实际同步缺口。差值 > 100000，基本可判定存在显著延迟，尤其在高事务量场景下
注意：TIME_COMPUTED 和 DATUM_TIME 字段也得一起看——如果这两个时间戳长期停滞不动，说明主库已停止探测备库，apply lag = 0 就是假象。
AWR 中哪些等待事件暗示备库延迟已传导到主库
当备库延迟严重时，主库也会“被拖慢”，尤其在 SYNC 模式下。这时 AWR 的 Top 5 Timed Events 会出现异常信号：
-
log file sync平均等待时间（Avg Wait ms）明显升高，且远高于log file parallel write：说明 LGWR 在等备库确认，根因在网络或备库 I/O，不是本地存储问题 -
control file sequential read出现高频、长等待：MRP 进程在备库频繁读控制文件校验日志头，常伴随V$MANAGED_STANDBY中CLIENT_PROCESS = 'MRP0'状态抖动 -
db file sequential read在备库 AWR 报告中单次读耗时突增（>20ms）：说明备库数据文件所在存储响应变慢，直接影响 apply 速度
别只盯着 SQL*Net message from client ——它高占比通常是客户端处理慢，和 DG 延迟无关；真由 DG 引发的主库阻塞，一定体现在 redo 相关等待上。
