必须在主库查询V$DATAGUARD_STATS，因该视图仅主库存在且依赖其主动探测；apply lag和transport lag为INTERVAL类型，须用EXTRACT提取秒数；延迟为0不等于实时同步，需校验SCN差值。
查 V$DATAGUARD_STATS 必须在主库，备库执行会报 ORA-00942
这个视图只在主库有有效数据，不是权限问题，是 Oracle 内部设计决定的——它依赖主库对备库状态的主动探测和聚合。很多 DBA 在备库反复执行 SELECT * FROM V$DATAGUARD_STATS 却没结果，就误以为监控失效，其实是位置错了。
实操前确认三件事：
- 当前用户有
SELECT_CATALOG_ROLE或显式授予SELECT权限 -
STATISTICS_LEVEL参数为TYPICAL（默认满足，但需用SHOW PARAMETER STATISTICS_LEVEL验证） - 字段名严格区分大小写且含空格：
WHERE NAME = 'apply lag'，不能写成'apply_lag'或漏掉空格
apply lag 和 transport lag 是 INTERVAL DAY TO SECOND 类型
它们返回类似 +00 00:05:23 的字符串格式，不是秒数。直接在 WHERE 条件里写 apply_lag > 60 会报类型不匹配错误。
脚本或告警中要提取秒数，必须用 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当纯数字处理 - PL/SQL 中未转换就做数值判断，条件永远为 false
- OEM 或 Zabbix 告警规则填了阈值但没指定单位类型，实际比对失效
查 V$ARCHIVE_GAP 要在备库，有结果就说明断档
这是最轻量、最可靠的 GAP 检查入口。只要返回任意一行，就说明该线程缺失一段连续归档日志序列，必须人工干预。
正确操作流程：
- 在备库执行：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; - 若有结果，按
THREAD#分别去主库查对应日志：SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD# = X AND SEQUENCE# BETWEEN Y AND Z; - 拷贝后，在备库注册：
ALTER DATABASE REGISTER LOGFILE '/path/to/logfile.log';
容易忽略的细节：
- 误以为没数据 = 同步正常 → 实际可能 RFS 进程卡住，还没来得及接收新日志
- 只查
thread 1的 gap，漏掉其他线程（尤其 RAC 环境） - 拷完日志忘了注册，
V$ARCHIVE_GAP仍持续返回结果
看 V$MANAGED_STANDBY 判断 RFS 和 MRP 是否存活
这个视图在备库上能直观反映传输接收（RFS）和日志应用（MRP）进程状态，比查 V$ARCHIVE_DEST_STATUS 更及时。
关键字段含义：
-
PROCESS = 'RFS'：代表远程文件服务进程，负责接收主库发来的 redo；STATUS = 'IDLE'正常，'CONNECTED'或'WAIT_FOR_LOG'也属常规；若长期'NOT APPLYING'或为空，说明网络或参数配置异常 -
PROCESS = 'MRP0'：代表日志应用进程；STATUS = 'APPLYING_LOG'才算真正干活；若为'WAIT_FOR_LOG'且SEQUENCE#长期不更新，大概率是前面有 GAP 或归档目标空间满 -
DELAY_MINS字段值为负数时，表示 MRP 应用进度落后于 RFS 接收进度，属于正常缓冲行为；但若持续为正且增大，说明应用跟不上接收
注意：V$MANAGED_STANDBY 不显示历史延迟趋势，只反映当前快照，需配合定时轮询或日志分析才能定位缓慢恶化类问题。
