FAL_SERVER仅在主库归档存在、网络连通、参数匹配且监听正常时才自动拉取缺失归档；若归档被删、监听异常、DB_UNIQUE_NAME不一致或ARCH未完成归档，FAL将静默失效。
fal_server 在 oracle 11g data guard 中不是“开箱即用”的自动修复开关，它只在满足全部前置条件时才触发拉取行为；配置错一个字母、少一个网络连通环节，就会静默失效——根本不会报错，也不会重试。
确认 Gap 是否真由 FAL 覆盖
先别急着改参数。FAL_SERVER 只对「主库归档仍存在」的 Gap 有效，一旦归档被 RMAN 删除、覆盖、或因空间满未生成，FAL 就完全不工作。
- 在备库执行：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP—— 确认有 Gap - 立刻去主库查对应序列是否存在：
SELECT NAME, ARCHIVED, DELETED FROM V$ARCHIVED_LOG WHERE THREAD# = 1 AND SEQUENCE# BETWEEN 12345 AND 12347 - 若
DELETED = 'YES'或查不到记录，FAL_SERVER 配了也白配，必须走手工拷贝或增量恢复
FAL_SERVER 和 FAL_CLIENT 必须严格匹配
这两个参数本质是 Oracle Net Service Name，不是数据库名或实例名，且大小写敏感、不能含空格或特殊字符。
- 主库
DB_UNIQUE_NAME是PRIMARY，则备库的FAL_CLIENT必须设为'PRIMARY'（引号内完全一致） -
FAL_SERVER值必须是备库TNSNAMES.ORA中定义的、能连通主库的服务名，比如'PRIMARY_DB'，而不是'PRIMARY' - 主库监听器必须运行正常：
lsnrctl status输出中该 service_name 对应的 STATUS 是 READY，不是 BLOCKED 或 UNKNOWN - 备库用
tnsping PRIMARY_DB能通，且主库防火墙放行监听端口（默认 1521）
主库归档传输目标必须启用且角色匹配
FAL 请求会被主库拒绝，常见于 LOG_ARCHIVE_DEST_2 的 VALID_FOR 设置与当前数据库角色冲突。
- 主库执行：
SELECT DEST_ID, VALID_FOR, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2 - 若
VALID_FOR是(ONLINE_LOGFILES, PRIMARY_ROLE)，而主库当前是 STANDBY 角色（比如 switchover 后未切回），FAL 请求直接返回ORA-16057: DGID not set - 确保主库
LOG_ARCHIVE_DEST_STATE_2 = ENABLE，且ERROR列为空
验证 FAL 是否真在运行，而非仅参数存在
别只信 SHOW PARAMETER fal，要看实时日志和视图输出。
- 备库查生效值：
SELECT fal_server, fal_client FROM v$database—— 若返回 NULL 或空字符串，说明没生效（可能 ALTER SYSTEM 未加 SCOPE=BOTH） - 查备库
alert.log，搜索FAL或gap：正常应有类似FAL: Fetching gap sequence# 12345 from primary的记录；若无任何输出，说明 FAL 根本没发起请求 - 主库查
v$archive_dest_status中 dest_id=2 的STATUS和ERROR，若有ORA-12154或ORA-12514，说明 TNS 解析失败，FAL 请求被拦截
真正容易被忽略的是：FAL 进程是“按需启动、用完即停”的，它不会常驻后台。Gap 出现后，MRP 进程发现卡住，才会唤醒 FAL；但若上述任一条件不满足，FAL 就不会启动——你看到的只是 MRP 持续 WAIT_FOR_GAP，日志里一片安静。
