FAL归档间隙根本原因是备库“要不到日志”，主因包括FAL_SERVER指向错误、主库归档已删除或CONTROL_FILE_RECORD_KEEP_TIME过小；必须查V$ARCHIVE_GAP确认gap范围，验证主库归档是否存在，停MRP后手工注册，且须配对FAL_SERVER/FAL_CLIENT并确保LOG_ARCHIVE_CONFIG一致。
FAL 归档间隙（Gap）不是配置没生效，而是备库主动“要不到日志”——根本原因通常是 FAL_SERVER 指向错误、主库归档已删除、或控制文件记录过期。自动机制失效后，必须人工介入补日志或重建同步起点。
查清 gap 范围和线程号，别只看 alert.log
备库 alert.log 里出现 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 1173-1175 这类报错，只是表象。真正要确认 gap 的起止，得查 V$ARCHIVE_GAP 视图：
- 在备库执行：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; - 注意：该视图只返回当前未解决的最小 gap，如果有多段断档，修复一段后需再次查询
- 若返回空行，说明没有未识别的 gap；但不代表同步正常——可能
MRP进程卡死或归档应用被暂停
确认主库是否还存着这些归档日志
gap 存在 ≠ 主库一定丢了日志。先验证归档是否还在主库上，避免白忙一场：
- 在主库执行：
SELECT NAME, DELETED FROM V$ARCHIVED_LOG WHERE THREAD# = 1 AND SEQUENCE# BETWEEN 1173 AND 1175 AND DEST_ID = 1; - 如果
DELETED = 'YES'，说明已被 RMAN 清理，需从备份中恢复：RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 1173 UNTIL SEQUENCE 1175 THREAD 1; - 如果归档在 ASM 中，不能直接 scp：先用
RMAN COPY ARCHIVELOG '+DATA/...arc' TO '/tmp/...arc';导出到文件系统，再传到备库 - 别忽略
CONTROL_FILE_RECORD_KEEP_TIME参数值——若设得太小（如默认 7 天），旧的归档切换记录会被覆盖，V$ARCHIVE_GAP就查不到准确范围
手工注册归档日志前，必须停掉 MRP 进程
很多人跳过这步，直接 ALTER DATABASE REGISTER LOGFILE，结果日志注册了，MRP 却不应用——因为 MRP 正在运行时，注册操作会被忽略或延迟生效：
- 在备库执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 确认 MRP 已停：
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';应返回空行或STATUS = 'IDLE' - 拷贝归档到备库本地归档目录（路径必须和
LOG_ARCHIVE_DEST_1一致，否则注册失败） - 逐个注册：
ALTER DATABASE REGISTER LOGFILE '/u01/arch/1_1173_1164727119.dbf';（注意：不能用OR REPLACE批量注册，容易漏掉某一个） - 注册完再启 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
gap 修复后仍不同步？重点检查 FAL 配置是否生效
即使这次 gap 手工修好了，下次还会崩——如果 FAL_SERVER 和 FAL_CLIENT 没配对或没生效，FAL 机制就形同虚设：
- 在备库查：
SHOW PARAMETER fal_server;必须指向主库的DB_UNIQUE_NAME（不是服务名或主机名） - 在主库查：
SHOW PARAMETER fal_client;必须是备库的DB_UNIQUE_NAME - 两个库都要有
LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRIMARY,STANDBY)'，且两边名字严格一致（区分大小写） - 改完参数必须重启监听 + 重连，否则
FAL连接会因 TNS 解析失败而静默失败 - 测试 FAL 是否通：在备库手动触发一次
ALTER SYSTEM SWITCH LOGFILE;，观察主库alert.log是否有FAL request received类日志
FAL gap 表面是日志断档，实际是主备之间“信任链”断裂——注册日志只是缝合伤口，配对 FAL_SERVER/FAL_CLIENT、保证归档保留策略、校验 CONTROL_FILE_RECORD_KEEP_TIME，才是让伤口不再裂开的关键。
