查v$dataguard_stats必须在主库执行，备库无此视图；apply_lag和transport_lag为INTERVAL类型，需EXTRACT转换为秒；判断延迟应结合SCN差值、v$archive_gap及日志应用状态综合分析。
查 v$dataguard_stats 必须在主库执行，备库查不到
这个视图只在主库有有效数据，备库执行会返回空或报 ORA-00942: table or view does not exist。不是权限问题，是 Oracle 内部设计如此——它依赖主库对备库状态的主动探测和聚合。
实操建议：
- 登录主库实例，确认用户有
SELECT_CATALOG_ROLE或直接对v$dataguard_stats的SELECT权限 - 执行前先检查：
SHOW PARAMETER STATISTICS_LEVEL，必须为TYPICAL（默认即满足），否则字段全为空 - 字段名严格区分大小写，正确写法是
WHERE NAME = 'apply lag'（带空格），不能写成'apply_lag'或模糊匹配
apply_lag 和 transport_lag 是 INTERVAL 类型，不是秒数
这两个字段返回的是类似 +00 00:05:23 的格式，表示“5 分 23 秒”，不是整数秒。直接拿它做数值比较会报类型不匹配错误。
常见错误现象：
- Shell 脚本里用
awk截取字符串失败，把+00 00:05:23当纯数字处理 - PL/SQL 中未用
EXTRACT或NUMTODSINTERVAL转换，导致IF apply_lag > INTERVAL '60' SECOND永远不成立 - EM 13c 告警规则填了数值阈值但没选对“单位类型”，实际比对失效
正确提取秒数的 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';别只看 current_scn 差值判断延迟
主库 current_scn 持续增长，而备库的 current_scn 只在日志应用后才更新。如果备库没开实时应用（recovery_mode = 'MANAGED STANDBY'），它的 current_scn 天然滞后，甚至长时间不动——这不是异常，只是应用模式导致的。
正确做法：
- 主库查
v$database.current_scn - 备库查
v$database.current_scn + v$managed_standby.sequence#（MRP 正在处理的日志序号）交叉验证 - 若差异持续超过 50 万 SCN，再结合
v$archive_gap和告警日志进一步排查
用 v$archive_gap 确认是否存在日志断档
这个视图只在备库可查，专门暴露“该收的日志没收到”的缺口。只要它返回记录，就说明主库生成了某段连续序号的日志，但备库 RFS 进程压根没拿到——这是比 SCN 差异更严重的信号，因为后续日志即使能传，也无法跳过这个 gap 应用。
实操注意点：
- 必须确保
LOG_ARCHIVE_DEST_n配置了VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)并启用了 FAL（Fetch Archive Log） - 发现 gap 后，优先在主库查
v$archived_log定位缺失日志路径，再手动scp到备库归档目录 - 最后在备库执行
ALTER DATABASE REGISTER LOGFILE '/path/to/missing.log'注册
真正决定“能不能查到主库刚提交的数据”，不是 apply_lag 显示多少秒，而是备库当前已应用的 SCN 是否 ≥ 主库事务提交时的 SCN。这个细节常被忽略，却直接影响应用端一致性判断。
