必须在主库查询v$dataguard_stats获取真实延迟值，备库该视图不可用；apply lag和transport lag为interval类型，需提取秒数；延迟为0不保证实时可见性，须校验scn差值；采样应连续取峰值而非单次结果。
必须在主库查 v$dataguard_stats，备库查不到有效数据
这个视图只在主库上能返回真实延迟值，备库执行 select * from v$dataguard_stats 会返回空行或直接报 ora-00942: table or view does not exist。这不是权限问题，是 oracle 内部设计：它依赖主库主动探测和聚合备库状态。很多 dba 在备库反复尝试失败后以为监控失效，其实是连错实例了。
实操建议：
- 先确认当前连接的是主库：
SELECT DATABASE_ROLE FROM V$DATABASE，结果必须是PRIMARY - 检查统计级别：
SHOW PARAMETER STATISTICS_LEVEL，值必须为TYPICAL（默认满足），否则该视图所有字段全为空 - 字段名严格区分大小写且含空格，别写成
'apply_lag'或'applylag'，正确写法是'apply lag'
apply lag 和 transport lag 是 INTERVAL 类型，不能直接比数字
这两个字段返回的是类似 +00 00:05:23 的 INTERVAL DAY TO SECOND，不是秒数。直接在 WHERE 条件里写 apply_lag > 300 会触发类型不匹配错误；Shell 脚本用 awk 截取时也容易把 + 或空格当分隔符切歪。
正确提取秒数的 SQL 是：
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';
注意：别漏掉 WHERE NAME = 'apply lag'，否则可能查到多行或无效记录。
延迟峰值 ≠ 实时可见性，apply lag = 0 不代表能立刻查到新数据
即使 apply lag 显示 +00 00:00:00，应用端仍可能查不到主库刚提交的数据。因为该值是基于日志头时间戳与系统时钟差估算的，不反映真实 SCN 同步进度。
真正决定“能不能读到”的，是备库当前已应用的 SCN 是否 ≥ 主库事务提交时的 SCN。所以监控延迟峰值时，必须配合校验：
- 主库获取当前 SCN：
SELECT CURRENT_SCN FROM V$DATABASE - 备库查已应用 SCN：
SELECT CURRENT_SCN FROM V$DATABASE@standby_db_link（需提前建好 DB Link） - 计算差值：
(主库 SCN - 备库已应用 SCN)，再用SCN_TO_TIMESTAMP转成时间差
这个差值才是影响只读查询一致性的关键，也是很多告警脚本遗漏的环节。
脚本中抓峰值要避免采样抖动，别只看单次查询结果
V$DATAGUARD_STATS 的 TIME_COMPUTED 字段说明该值是定时计算的快照，不是实时流。一次查询看到的 apply lag = +00 00:00:01 可能只是瞬时抖动，不代表持续延迟。
要捕获真实峰值，得连续采样并保留最大值。比如在 Shell 脚本里：
- 每 30 秒查一次，用
awk提取秒数，存入临时文件 - 每次更新前先比较，只保留更大值：
if [ $new_sec -gt $max_sec ]; then max_sec=$new_sec; fi - 别依赖
MAX(apply_lag_seconds)这种聚合——字段类型不支持直接聚合，必须先转秒再算
另外，如果主库配置了 LOG_ARCHIVE_DEST_2 为 SYNC AFFIRM，LNS 等待 ACK 会造成 transport lag 偶发尖刺，这时光看 apply lag 会漏掉传输层瓶颈。
