必须在主库查询v$dataguard_stats获取真实延迟值，备库该视图不可用；apply lag字段需严格匹配名称并用extract提取秒数；延迟为0不等于scn同步，须比对current_scn与applied_scn；mrp0卡在wait_for_log需启用real-time apply并检查standby redo log、lgwr传输及delay参数。
必须在主库查 V$DATAGUARD_STATS，备库查不到真实延迟值
备库执行 SELECT * FROM V$DATAGUARD_STATS 要么报 ORA-00942: table or view does not exist，要么返回空行——这不是权限问题，是 Oracle 内部设计决定的。该视图只在主库内存中构建，依赖主库主动探测和聚合备库状态。常见误操作是在备库反复重试、或用监控工具连备库取这个视图，结果为空就以为“监控失效”。
正确做法：所有延迟监控脚本、告警逻辑、巡检 SQL 都必须连接主库执行。如果业务系统只能访问备库，需通过 DB Link 或中间服务代理查询主库视图。
apply lag 字段是 INTERVAL DAY TO SECOND 类型，不能直接比大小
字段名严格为 'apply lag'（含空格），写成 'apply_lag' 或 'applylag' 会查不到；且必须加 WHERE NAME = 'apply lag'，否则可能返回多行或无关记录。
提取秒数必须用 EXTRACT 函数，例如：
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';
Shell 脚本里若用 awk 解析原始输出（如 +00 00:05:23），开头的 + 和空格极易切歪，建议统一由 SQL 提取为整数秒后再传给脚本处理。
延迟为 0 不代表能查到最新数据，必须核对 CURRENT_SCN 和 APPLIED_SCN
V$DATAGUARD_STATS 中的 apply lag 是基于日志头时间戳与系统时钟差的估算值，不反映真实 SCN 同步进度。即使显示 +00 00:00:00，应用端仍可能查不到主库刚提交的数据。
- 主库查：
SELECT CURRENT_SCN FROM V$DATABASE - 备库查：
SELECT APPLIED_SCN FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 1（或查V$DATAGUARD_STATS中latest applied scn字段）
两者的差值才是实际同步缺口。若差值持续不缩小，说明 MRP0 进程卡住，需立刻查 V$MANAGED_STANDBY 的 PROCESS 和 STATUS 列。
MRP0 卡在 WAIT_FOR_LOG？大概率是没启用 real-time apply
查 V$MANAGED_STANDBY 发现 MRP0 状态为 WAIT_FOR_LOG，且 RFS 已收到最新日志序列（SEQUENCE# 匹配主库），说明不是传输问题，而是备库默认不实时应用主库正在写的联机日志（current online log）。
要解决，必须满足三个条件：
- 备库已配置 standby redo log（
V$STANDBY_LOG中状态不能是UNASSIGNED） - 主库
LOG_ARCHIVE_DEST_n使用LGWR SYNC或LGWR ASYNC，且未设DELAY= - 备库启动 real-time apply：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
漏掉任一条件，MRP0 就会等归档完成才开始应用，导致明显延迟。尤其注意：如果主库设置了 DELAY=，real-time apply 会被静默忽略，alert log 里只有一行 WARNING: ... DELAY ... ignored，容易被忽略。
