Client-Side TAF 是被动故障转移，依赖客户端配置和连接断开后重试；FCF 是主动通知机制，基于FAN事件驱动、需服务端启用FAN及连接池支持，实现毫秒级失效感知与连接预清理。
Client-Side TAF 和 FCF 的核心区别在哪
TAF 是 Oracle Net 层的被动故障转移机制，依赖客户端 tnsnames.ora 中的 FAILOVER_MODE 配置；FCF（Fast Connection Failover）是基于 FAN（Fast Application Notification）事件的主动通知机制，必须配合连接池（如 WebLogic UCP、Oracle UCP）和数据库服务端启用 FAN 才能生效。TAF 在连接断开后“感知并重建”，FCF 在故障发生前就“收到通知并预清理”。
什么时候必须用 FCF 而不能只靠 TAF
以下场景中 TAF 无法覆盖，FCF 是刚需：
- 应用使用连接池且要求**毫秒级故障感知**（比如金融交易类系统），TAF 的
DELAY/RETRIES会引入不可控延迟（典型 5–15 秒） - 连接池中存在大量空闲连接，TAF 不会主动验证或驱逐失效连接，而 FCF 通过 FAN 事件实时通知连接池失效节点，自动剔除坏连接
- 数据库服务启用了
ENABLE=BROKEN或动态服务注册（srvctl add service -f），但客户端未配置FAILOVER_MODE—— 此时 TAF 根本不触发，FCF 却仍可工作 - 应用部署在 WebLogic/Tomcat 等容器中，且已启用 UCP 或 Oracle JDBC Universal Connection Pool：这些池原生支持 FCF，但对 TAF 仅做有限兼容（例如不处理 TYPE=select 的游标续查）
TYPE=select + METHOD=PRECONNECT 与 FCF 能否共存
不能。二者底层逻辑冲突：
-
TYPE=select要求 Oracle 服务端为每个 session 保留游标上下文，这依赖稳定的服务端状态同步，而 FCF 触发时连接池会立即关闭所有指向故障实例的物理连接，导致游标上下文丢失 -
METHOD=PRECONNECT会让单个逻辑连接占用多个物理连接（如 4 节点 RAC → 4 个 socket），FCF 的连接驱逐动作会放大资源抖动，容易触发ORA-12516或监听器拒绝新连接 - 实测表明：同时启用两者时，JDBC 驱动可能卡在重连阶段，
SQLRecoverableException抛出频率反而上升，尤其在高并发短连接场景下
真实压测中更稳妥的做法是：FCF 场景统一用 TYPE=session + METHOD=BASIC，把故障恢复交给连接池自身的健康检查与重建逻辑，而非依赖 Oracle 服务端游标续查。
FCF 启用失败最常见的三个漏点
FCF 看似只需配连接池开关，但实际有三个硬性依赖常被忽略：
- 数据库服务必须通过
srvctl add service -s <svc> -r <insts> -y AUTOMATIC -q TRUE -e SELECT -m BASIC -z 180 -w 5注册，其中-q TRUE（启用 FAN）和-e SELECT（启用服务端事件发布）缺一不可 - 客户端主机必须能解析数据库集群的 SCAN 名称和所有 VIP，且
/etc/hosts中不能有错误条目——否则 FAN UDP 包无法送达，表现为连接池始终不响应故障 - JDBC URL 中必须显式包含
loadBalance=true&failover=true&oracle.jdbc.fanEnabled=true，仅设fanEnabled=true不够，loadBalance和failover是前置使能开关
最隐蔽的问题是：即使 FCF 配置全对，若数据库监听器未启用 ENABLE_GLOBAL_DYNAMIC_REGISTRATION=ON（12c+ 默认开启，但某些加固策略会关），FAN 事件根本不会广播，连接池也就收不到任何通知。
