v$archive_gap是唯一可信的归档缺口判断依据，返回非空即确认RFS未收到归档；空行表示RFS接收正常但MRP应用层异常；多行输出对应不连续缺口，需分段处理并校验。
查 v$archive_gap 是唯一可信的缺口判断依据，返回非空即确认 RFS 没收到归档，不是“可能断档”，而是已经断档。
为什么只看 v$archived_log 最大 SEQUENCE# 会误判
常见错误是看到备库 v$archived_log 里最后一条是 SEQUENCE# = 100，就以为缺 101，结果 v$archive_gap 显示缺的是 95–99 —— 因为中间几段归档压根没进控制文件，v$archived_log 根本不记录它们。
-
v$archive_gap反映的是 RFS 进程实际缺失的物理归档范围，由 Oracle 内部比对主库发送序列和本地接收序列得出 -
v$archived_log只显示“已被注册进控制文件”的归档，传输失败、磁盘满、手动删档都会导致条目缺失 - RAC 环境下必须按
THREAD#分别查，不能只查默认线程
v$archive_gap 返回空行意味着什么
空行 ≠ 同步正常，而是说明 RFS 接收没问题，问题在 MRP 应用层（比如卡在 ORA-01111 或归档目录 I/O 延迟高）。
- 此时应立刻查
v$managed_standby：确认MRP0进程状态是否为APPLYING_LOG - 检查
alter.log是否有Media Recovery Log消息，或长时间停在某条日志 - 若
MRP0状态为WAIT_FOR_LOG，大概率是归档文件存在但 SCN 不连续，需用VALIDATE DATABASE ARCHIVELOG ALL校验
多行输出时如何分段处理
返回多行说明缺口不连续，例如：
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# 1 9873 9876 1 9880 9882
这意味着 9873–9876 和 9880–9882 两段都缺失，中间 9877–9879 可能已收到但未应用，也可能根本没传过来（需结合 v$managed_standby 的 SEQ# 字段确认 RFS 当前接收位置）。
- 每段必须单独在主库查路径：
SELECT NAME FROM v$archived_log WHERE THREAD# = 1 AND SEQUENCE# BETWEEN 9873 AND 9876 AND DEST_ID = 1; - 手工拷贝时注意文件属主：
chown oracle:oinstall，否则注册会失败 - 注册顺序无关紧要，但必须全部注册完再启动恢复，否则 MRP 仍会卡住
真正容易被忽略的是：FAL_SERVER 静默失效后，v$archive_gap 依然会持续增长——它不会告诉你 FAL 尝试过但失败了，只会安静地等你去查。
