v$archive_gap返回非空结果即确认RFS未收到归档，LOW_SEQUENCE#至HIGH_SEQUENCE#为真实缺口范围；空行说明问题在MRP层，多行需分段处理，RAC须按THREAD#分别检查。
v$archive_gap 返回非空结果，就说明FAL GAP已经发生——不是“可能”，而是RFS进程确实没收到那些归档段。
查 v$archive_gap 是唯一可信的缺口判断依据
备库上执行 SELECT * FROM v$archive_gap;，输出的 LOW_SEQUENCE# 和 HIGH_SEQUENCE# 就是 RFS 进程缺失的归档范围。常见错误是只看 v$archived_log 里最大 SEQUENCE# 是 100，就以为缺 101，结果 v$archive_gap 显示缺的是 95–99，白忙活半天。
如果返回空行，说明 RFS 接收没问题，问题在 MRP 应用层（比如卡在 ORA-01111）；如果返回多行，说明缺口不连续，需分段处理；RAC 环境下必须按 THREAD# 分别查、分别传。
FAL_SERVER 静默失效是常态，不是配置完就自动工作
FAL 机制依赖备库主动“拉取”，但实际中极易静默失败：alert.log 没报错 ≠ 没尝试过，可能是超时后直接放弃，连日志都不写。常见原因包括：
-
FAL_SERVER参数未设或指向错误的DB_UNIQUE_NAME（不是 TNS 别名） - 主库
LOG_ARCHIVE_DEST_1目录权限不对，Oracle 用户无法读取归档文件 - 主库归档已删除（
DELETED = 'YES'），FAL 请求返回空，但不会报错 - 主库
CONTROL_FILE_RECORD_KEEP_TIME太小，导致v$archived_log里查不到旧序列号记录
网络与存储瓶颈比参数配置更常触发 GAP
GAP 表象是日志断档，根因往往不在 SQL 层：
- 网络闪断或高延迟（跨地域 RTT > 100ms），LNS 进程发包失败，RFS 收不到任何内容
- 主库归档生成速率超过网络带宽（如批量加载时 redo 达 15MB/s，而链路仅 1Gbps）
- 备库归档目录所在磁盘 I/O 延迟高，ARCH 进程写归档慢，
log file sync等待堆积 - 主库
log_archive_dest_state_2被意外设为DEFER或RESET，日志发送彻底中断
手动注册归档比等 FAL 更快更可控
只要主库归档还在，且网络通、TNS 可解析，手工拷贝 + 注册比依赖 FAL 更可靠：
- 先在主库确认文件存在：
SELECT NAME FROM v$archived_log WHERE SEQUENCE# BETWEEN 1173 AND 1175 AND DEST_ID = 1; - 用
scp拷到备库本地归档路径（如/u01/arch/），注意chown oracle:oinstall - 在备库执行：
ALTER DATABASE REGISTER OR REPLACE PHYSICAL LOGFILE '/u01/arch/1_1173_1164727119.dbf'; - 注册完立刻启动恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
真正容易被忽略的是：FAL 不会帮你检查主库归档是否真实存在，也不会告诉你它根本没找到文件——它只是安静地放弃。动手前，务必先跑一遍 v$archive_gap 和主库 v$archived_log 查询，否则所有后续操作都在赌运气。
