FAL_SERVER仅在主库归档存在且网络、参数、角色匹配时才自动拉取缺失归档；若归档被删、监听异常、DB_UNIQUE_NAME不一致或ARCH未完成归档，FAL将静默失效。
fal_server 参数在 oracle 11g data guard 中确实能自动拉取缺失归档，但它只对“主库归档日志仍存在”的 gap 有效，且必须配合 fal_client 和正确网络配置才能生效。一旦归档被删除、覆盖或主库归档路径空间满导致日志未生成，fal_server 就完全失效。
为什么 FAL_SERVER 不起作用？常见失效场景
你执行 SELECT * FROM v$archive_gap; 发现 gap，但备库 alert.log 里没有 FAL 相关重试日志，说明 FAL 根本没触发——这不是配置漏了，而是前置条件不满足：
-
FAL_SERVER要求主库监听器正常运行，且备库能通过TNSNAMES.ORA中定义的 service_name 连通主库；若主库 listener 状态为 BLOCKED 或防火墙拦截端口，FAL 请求直接超时静默失败 - 主库
LOG_ARCHIVE_DEST_2的VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)必须与备库角色匹配，否则主库拒绝响应 FAL 请求（错误如 ORA-16057: DGID not set） - 主库归档目录（
LOG_ARCHIVE_DEST_1）下必须存在 gap 范围内的所有归档文件；若已被 RMANDELETE ARCHIVELOG清理，FAL 查不到源文件，不会报错也不会重试 - 备库
FAL_CLIENT值必须和主库DB_UNIQUE_NAME完全一致（区分大小写），且不能含空格或特殊字符；输成'PRIM'而主库是'PRIMARY'就会导致 FAL 认证失败
检查 FAL 是否真在工作：别只看参数值
设置完 FAL_SERVER 和 FAL_CLIENT 后，不能只查 SHOW PARAMETER fal。关键要看实时行为：
- 在备库执行：
SELECT fal_server, fal_client FROM v$database;—— 确认值已生效（不是空或 NULL） - 查备库 alert.log，搜索
FAL或gap，正常应有类似FAL: Fetching gap sequence# 12345 from primary的记录；若无任何输出，说明根本没发起请求 - 在主库执行：
SELECT dest_id, status, error FROM v$archive_dest_status WHERE dest_id = 2;—— 若status是ERROR或error列有内容（如 ORA-12154），FAL 请求会被直接拒收
手动触发 FAL 补救：绕过自动机制的应急操作
当确认主库归档存在、网络通畅、参数正确，但 MRP 仍卡在 gap 处，可强制让 FAL 重新扫描：
- 先停掉恢复进程：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 在备库 SQL*Plus 中手动调用 FAL 接口：
EXECUTE DBMS_BACKUP_RESTORE.FAL_REQUEST('PRIMARY', 12345, 12347);（把 12345/12347 换成v$archive_gap返回的实际 low_seq/high_seq） - 再启动恢复：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 注意：该
DBMS_BACKUP_RESTORE.FAL_REQUEST是未公开包，仅限 11g 使用；12c+ 已弃用，改用RECOVER ... FROM SERVICE
真正容易被忽略的点
FAL 的日志拉取依赖主库的 ARCH 进程主动归档，而不是 LGWR 实时推送。如果主库 LOG_ARCHIVE_DEST_2 配置为 SYNC 模式，ARCH 进程可能因网络延迟积压，导致 gap 对应的归档还没来得及生成到 LOG_ARCHIVE_DEST_1，FAL 就查不到。此时需先检查主库 v$archive_processes 中 ARCH 状态是否为 WAIT_FOR_LOG，而非盲目调大 FAL 超时参数。
