直接查看APPLY_LAG和TRANSPORT_LAG可快速定位备库延迟环节；需在备库执行v$dataguard_stats，字段为小写，time_computed为统计更新时间戳，二者均为SCN差换算的时间估算值，非绝对挂钟延迟。
直接看 APPLY_LAG 和 TRANSPORT_LAG 两个字段，就能快速判断备库延迟是卡在传输还是应用环节——这是最常用、最可靠的起点。
查 v$dataguard_stats 必须在备库执行
这个视图只在物理备库（包括 ADG）上有实际数据，主库查出来全是空或默认值。如果连不上备库、或误在主库执行 SELECT * FROM v$dataguard_stats，结果会误导你认为“没延迟”，其实根本没取到有效指标。
- 连接目标必须是备库实例，且用户需有
SELECT ANY DICTIONARY或至少对V_$DATAGUARD_STATS的查询权限 - Oracle 12c 及以后版本中，该视图字段名统一为小写（如
name,value,unit,time_computed），不再用大写别名 -
time_computed是关键时间戳，代表该条统计值的最后计算时刻，不是当前系统时间；若它停滞不前，说明 DG 同步已中断或 MRP 进程异常
APPLY_LAG 和 TRANSPORT_LAG 的真实含义
很多人把这两个值简单理解为“秒数”，但它们本质是 SCN 差异换算出的时间估算值，受备库当前 SCN 推进速度影响，并非绝对精确的挂钟延迟。
-
APPLY_LAG：表示“如果现在停止应用，备库数据比主库落后多少时间”。它反映的是日志应用瓶颈，比如 I/O 慢、CPU 不足、SQL 应用冲突等 -
TRANSPORT_LAG：表示“主库生成日志后，多久才传到备库归档目录”。它反映的是网络、主库 LGWR/RFS 配置、备库磁盘写入能力等问题 - 若
TRANSPORT_LAG很小（APPLY_LAG 持续增长，问题一定在备库本地（如 IO 被报表任务打满、standby_file_management设为 MANUAL 导致文件创建失败） - 若两者同步上涨，大概率是主库归档压力大或网络抖动，先查
v$archive_dest_status中对应DEST_ID=2的STATUS和ERROR列
别忽略 VALUE 字段的单位陷阱
v$dataguard_stats 的 UNIT 列决定数值解读方式——它不是固定为“seconds”，不同项单位差异很大，硬套会导致误判。
-
APPLY_LAG和TRANSPORT_LAG的UNIT是days，但VALUE是以“天”为单位的小数（例如0.000123天 ≈ 10.6 秒），需手动换算：乘以 86400 才得秒数 -
APPLY_RATE单位是MB/sec，而TRANSPORT_SPEED单位是KB/sec，混看会高估传输能力 -
ESTIMATED_REMAINING_TIME（19c+）单位是seconds，可直接读，但它只是基于当前速率的粗略预测，MRP 一旦暂停就失效
配合 v$managed_standby 看进程状态
单靠 v$dataguard_stats 只能看到“结果”，看不到“过程”。真正卡住时，往往是因为某个关键进程挂了或卡死。
- 执行
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM v$managed_standby WHERE PROCESS IN ('MRP0', 'RFS') -
MRP0状态不是APPLYING_LOG？说明日志应用已停，此时APPLY_LAG会持续上涨，但v$dataguard_stats不报错 -
RFS状态是IDLE但TRANSPORT_LAG在涨？检查主库v$archive_dest_status是否有ERROR，或备库监听器是否响应 RFS 连接 - 注意
SEQUENCE#是否长时间不更新——哪怕状态显示正常，序列号冻结也意味着同步实质停滞
真正难排查的延迟，往往藏在 time_computed 停滞、MRP0 状态异常、或 UNIT 换算错误这三处。盯住这三个点，比反复刷 v$dataguard_stats 更有效。
