V$DATAGUARD_STATS中transport lag仅主库可查，需用EXTRACT提取秒数，TIME_COMPUTED滞后超1分钟则数据过期；RFS状态与V$ARCHIVE_DEST_STATUS需交叉验证传输健康度。
主库查 V$DATAGUARD_STATS 是唯一可靠入口
传输延迟（transport lag）只能在主库查，备库执行会返回空或报 ORA-00942。这不是权限问题，是 Oracle 内部设计：该视图依赖主库对备库的主动探测逻辑，备库没有对应统计上下文。
实操前确认三件事：
- 当前用户有 SELECT_CATALOG_ROLE 或对 V$DATAGUARD_STATS 的显式 SELECT 权限
- STATISTICS_LEVEL 参数为 TYPICAL（默认满足，但需用 SHOW PARAMETER STATISTICS_LEVEL 验证）
- 查询时字段名严格带空格：WHERE NAME = 'transport lag'，不能写成 'transport_lag' 或大小写混用
transport lag 是 INTERVAL 类型，不能直接比数字
它的值形如 +00 00:02:17，是 INTERVAL DAY TO SECOND 类型。直接写 transport_lag > 60 会触发 ORA-00932 类型不匹配错误。
提取秒数必须用 EXTRACT：
SELECT EXTRACT(DAY FROM transport_lag) * 86400 +
EXTRACT(HOUR FROM transport_lag) * 3600 +
EXTRACT(MINUTE FROM transport_lag) * 60 +
EXTRACT(SECOND FROM transport_lag) AS transport_lag_seconds
FROM V$DATAGUARD_STATS
WHERE NAME = 'transport lag';
注意：TIME_COMPUTED 字段时间戳若滞后于当前系统时间超过 1 分钟，说明该延迟值已过期，不能反映真实状态——先看这个再看数值。
RFS 进程状态是判断传输是否卡住的关键信号
在备库查 V$MANAGED_STANDBY，重点盯 PROCESS = 'RFS' 的 STATUS：
- IDLE：日志已收全，传输层无瓶颈
- CONNECTED 或 WAIT_FOR_LOG：RFS 正在连主库或等新日志，但可能卡在防火墙、网络抖动、主库 LOG_ARCHIVE_DEST_n 配置异常（比如漏了 LGWR）
- ERROR 或空行：RFS 进程崩溃或未启动，立刻查备库 alert.log
别只盯着 transport lag 数值——如果 RFS 是 IDLE 但 transport lag 很大，大概率是 TIME_COMPUTED 没刷新；如果 RFS 是 CONNECTED 且持续不更新 SEQUENCE#，就要查网络和主库归档配置了。
传输延迟高 ≠ 主库没发，得交叉验证 V$ARCHIVE_DEST_STATUS
在主库查 V$ARCHIVE_DEST_STATUS，重点关注目标备库对应 DEST_ID 的几列：
- STATUS：必须是 VALID，不是 ERROR 或 INACTIVE
- TRANSMIT_MODE：应为 SYNC 或 ASYNC，不能是 ARCH（表示靠归档进程推，不实时）
- PROTECTION_MODE：若设为 MAXIMUM PROTECTION 却出现延迟，说明 LGWR 同步被阻塞，优先查网络和备库响应
- ERROR 列：非空则直接按提示处理，比如 ORA-16057: DGID not set 表示 Data Guard 配置未生效
一个常被忽略的点：DELAY= 参数在 LGWR SYNC 模式下会被无视，但监控脚本若误读该字段，会得出错误结论。
