FAL_SERVER指定standby向哪个数据库拉日志，FAL_CLIENT是standby在请求中声明的自身TNS别名，用于primary反向连接；二者需互相解析、网络可达，且FAL_CLIENT必须指向本机监听器。
什么是 FAL_SERVER 和 FAL_CLIENT 的实际作用
fal（fetch archive log）机制是 oracle data guard 中用于自动补传缺失归档日志的核心组件，fal_server 和 fal_client 不是服务端/客户端的“角色”，而是两个独立配置项，分别控制“谁去拉日志”和“拉日志时告诉对方自己是谁”。fal_server 指定 standby 节点向哪个（或哪些）数据库发起日志请求；fal_client 是 standby 自己在请求中声明的 tns 别名，供 primary 用来反向连接回该 standby（比如做日志验证或响应）。两者必须能互相解析、网络可达，且 fal_client 对应的 tns 条目必须指向本机监听器。
FAL 请求失败的典型现象与排查路径
最常见的表现是 standby 的 alert 日志反复出现：ORA-16055: FAL request rejected 或 WARNING: FAL client failed to connect to FAL server，同时 V$ARCHIVE_GAP 显示持续存在归档缺口。这不是网络不通就完事了——重点检查三点：
-
FAL_SERVER值是否拼写正确，且该 TNS 别名在 standby 的$ORACLE_HOME/network/admin/tnsnames.ora中存在并可tnsping通 -
FAL_CLIENT值是否对应 standby 本地有效的 TNS 别名，且该别名的HOST指向本机（不能是localhost或127.0.0.1，除非监听器明确绑定了 loopback） - primary 上是否能用
sqlplus /@<code>FAL_CLIENT成功连接 standby —— 这步常被跳过，但它是 FAL 反向通信的前提
FAL_SERVER 配置多个值时的行为细节
FAL_SERVER 支持逗号分隔多个 TNS 别名（如 'prmy1,prmy2'），但 Oracle 并不轮询或负载均衡：它只尝试列表中第一个可用的，失败即报错，不会自动 fallback 到第二个。这意味着多值配置仅适用于主库有多个可选实例（如 RAC 多节点）且你确信它们共享同一归档位置的情形。若 primary 是单实例，配多个值纯属冗余，还可能因第一个不可达导致 FAL 卡住。另外，FAL_SERVER 不支持别名展开（比如不能写成 '(DESCRIPTION=...)'），必须是 tnsnames.ora 中定义的简短别名。
为什么有时设置了 FAL 却仍靠手动拷贝归档
根本原因在于 FAL 只负责“已生成但未传输到 standby”的归档日志，它不处理以下场景：
- primary 归档日志已被删除（
DELETE ARCHIVELOG或 RMAN 清理后），FAL 拉不到，只能人工恢复 - standby 启动时
ARCHIVE_LAG_TARGET设置过大，或LOG_ARCHIVE_DEST_n的DELAY属性生效，导致日志在 primary 端滞留超时，FAL 触发前 gap 已扩大 - standby 处于
MOUNT状态但未启用RECOVER MANAGED STANDBY DATABASE，FAL 进程根本不会启动
真正依赖 FAL 的，只是那些因网络抖动、临时监听故障等导致的短暂传输中断。一旦日志在 primary 上消失，或者 standby 长时间未应用，FAL 就无能为力了。
