applied='yes'仅表示归档日志被mrp读取，未必已应用；连续多个applied='no'且first_time密集（秒级）表明重做流积压；应过滤1小时内数据查sequence#连续性，超5～10个需干预，blocks异常偏小亦为风险信号。
查 v$archived_log 看 applied 状态是否真实推进
applied='yes' 不等于数据已同步——它只表示该归档日志文件被 mrp 进程“读过”，但未必成功应用。真正关键的是连续性：如果 v$archived_log 中从某 sequence# 开始，后续大量记录的 applied 仍为 'no'，且 first_time 时间戳密集（秒级间隔），大概率是重做流积压而非传输失败。
执行时加时间过滤避免全表扫：
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, BLOCKS, APPLIED FROM v$archived_log WHERE FIRST_TIME > SYSDATE - 1/24 ORDER BY SEQUENCE#;
- 重点盯住
APPLIED = 'NO'的连续段长度，超过 5～10 个就需干预 -
BLOCKS异常偏小（如 FIRST_TIME 密集，是DBMS_REDEFINITION类操作引发重做风暴的典型指纹 - 别只看最后几行——积压往往藏在中间，
SEQUENCE#跳变或停滞才是信号
用 v$managed_standby 确认 MRP 进程是否真在干活
v$managed_standby 显示 PROCESS = 'MRP0' 并不等于它在推进日志。常见静默卡死状态是 STATUS = 'APPLYING_LOG' 但 SEQUENCE# 几分钟不动，或反复卡在同一值上。
必须连查两次，间隔 10 秒以上：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, CLIENT_PROCESS FROM v$managed_standby WHERE PROCESS = 'MRP0';
- 若
SEQUENCE#不变、BLOCK#停滞，立刻查备库alert.log，搜ORA-01555、undo、corruption - 若根本查不到
MRP0行，说明恢复没启用，需手动执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 执行前先
CANCEL一次，避免残留锁导致新进程挂起
比对主备 v$log_history 的最大 sequence# 是否一致
主库 v$log_history 的 MAX(SEQUENCE#) 是它已切换出的归档总数；备库同字段反映它“理论上能收到”的上限。两者差值超过 2～3，基本可断定有 GAP 或应用滞后。
主库执行：
SELECT MAX(SEQUENCE#) FROM v$log_history;
备库执行相同语句，再对比。注意：
- 这个差值 ≠ 同步延迟，只是第一层粗筛。差 1 可能只是网络抖动，差 5 就得进
v$archive_gap细查 - 若备库差值为 0，说明 RFS 进程根本没收到任何归档，问题在传输链路（主库
LOG_ARCHIVE_DEST_2的STATUS或ERROR字段要立刻看） - 不要用
v$log的MAX(SEQUENCE#)比——那是当前联机日志序号，物理备库看不到主库的在线日志
检查实时应用是否真正开启（using current logfile）
即使备库处于 OPEN READ ONLY 状态，也不代表实时应用开着。必须确认 v$archive_dest_status 中 DEST_ID = 2（或对应备库目标）的 RECOVERY_MODE 是 MANAGED REAL TIME APPLY，而非 IDLE 或空值。
执行：
SELECT DEST_ID, DEST_NAME, STATUS, RECOVERY_MODE, ERROR FROM v$archive_dest_status WHERE DEST_ID = 2;
-
STATUS必须是VALID，ERROR字段为空，否则传输本身已中断 -
RECOVERY_MODE是MANAGED REAL TIME APPLY才算启用了USING CURRENT LOGFILE；若是MANAGED STANDBY，说明只应用归档，不接实时流 - 改模式不能直接 ALTER，必须先
CANCEL当前恢复，再用USING CURRENT LOGFILE重启
最易被忽略的一点：v$archived_log.APPLIED = 'YES' 只说明该归档被 MRP 进程处理过，不代表其中每条重做记录都成功落地。尤其在 DBMS_REDEFINITION 场景下，单个归档里可能含数千条小事务，MRP 卡在第 999 条就会让整个归档标记为 APPLIED = 'NO'，但日志文件本身早已接收完毕——此时看 v$archive_gap 会返回空，误判“无缺口”。必须结合 v$managed_standby 的 BLOCK# 推进和 alert.log 的报错交叉验证。
