最直接判断日志是否正在应用是查v$managed_standby中mrp0状态是否为applying_log且sequence#持续推进；若为wait_for_log或idle，则应用已卡住，需结合v$archive_gap、v$archive_dest_status及alert.log进一步定位根源。
别只看 current_scn 差值——它在备库没开实时应用时根本不能反映真实延迟。
查 v$managed_standby 确认 MRP 进程是否真在干活
这是最直接判断日志“正在被应用”的方式，不是看有没有进程名，而是看它的状态和序列号是否推进：
-
PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'才算真正运行中；若为IDLE或WAIT_FOR_LOG，说明应用已卡住 -
SEQUENCE#字段显示当前正在应用的日志序号，要和主库v$archived_log最新SEQUENCE#对比，差值超过 2–3 就得盯紧 - 如果
DELAY_MINS > 0，说明 MRP 自己报告了延迟（但注意：这个值可能不准，仅作参考） - RAC 环境下，每个实例的
v$managed_standby是独立的，必须逐实例查，不能只查一个节点
用 v$dataguard_stats 看 transport lag 和 apply lag
这个视图在主库查才有意义，单位是 INTERVAL DAY TO SECOND，比 SCN 更贴近业务感知：
-
TRANSPORT_LAG非零但APPLY_LAG = '+00 00:00:00'：常见于网络抖动导致归档传不过去，但已传的日志都应用完了 -
APPLY_LAG持续增大（比如从 +00 00:01:23 变成 +00 00:08:45）：优先检查备库v$archive_dest_status的ERROR字段，常暴露归档目录满、权限不对、TNS 解析失败 - 该视图依赖
STATISTICS_LEVEL = TYPICAL（默认满足），若查出来为空，先确认这个参数没被手动调成BASIC
查 v$archive_gap 判断是否有日志断档
这是比延迟更严重的问题——一旦出现 gap，后续日志无法跳过应用，同步必然中断：
- 该视图只在备库可查，返回任何记录都代表缺口存在（例如
THREAD# = 1, LOW_SEQUENCE# = 100, HIGH_SEQUENCE# = 105） - gap 出现后，
v$managed_standby中 RFS 进程可能仍显示ARCHIVING，但 MRP 会卡在 gap 前一个日志上不动 - 手工补 gap 要严格按顺序：先从主库查出缺失日志路径（
v$archived_log+SEQUENCE# BETWEEN ...），scp 到备库相同目录，再执行ALTER DATABASE REGISTER LOGFILE - 别指望 FAL 自动拉取——如果
LOG_ARCHIVE_DEST_n没配VALID_FOR=(STANDBY_LOGFILE,STANDBY_ROLE)，FAL 机制压根不生效
别漏掉备库 v$archive_dest_status 的 RECOVERY_MODE
很多“延迟大”其实是配置误解导致的，不是故障：
-
SELECT RECOVERY_MODE FROM v$archive_dest_status WHERE DEST_ID = 2返回MANAGED STANDBY：说明靠轮询归档日志应用，天然有分钟级延迟，current_scn差几十万很正常 - 返回
MANAGED REAL TIME APPLY才表示启用了 Standby Redo Log 实时应用，此时current_scn才具备可比性 - 如果返回
IDLE，MRP 根本没启动，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT才是正解，不是改 Broker 配置
真正难排查的从来不是“查不到延迟”，而是“查到延迟却找不到源头”——比如 apply lag 在涨，但 v$archive_dest_status.ERROR 是空的，这时得立刻切到备库看 alert.log 最后几行，Oracle 很多底层错误（如 standby redo log 文件损坏）根本不会进 v$dataguard_stats。
