UCP配置Oracle高可用连接池的核心是显式启用FAN事件驱动的快速故障转移：必须调用setFastConnectionFailoverEnabled(true)，配置ONS节点（如nodes=host1:6200,host2:6200），使用SCAN或多地址连接串，并确保数据库端已启用FAN。
UCP必须显式调用setFastConnectionFailoverEnabled(true)
FCF不是靠JDBC URL或连接属性自动启用的机制。哪怕你在URL里写了oracle.jdbc.fanEnabled=true，或者在setConnectionProperties里塞了相同键值，UCP池对象也完全无视——它只认自己身上的开关。
常见错误现象：RAC节点宕机后，应用持续向已下线实例发请求，报ORA-03113或IO Error: Connection reset，重试间隔长达20–30秒，连接池里堆满失效连接。
- PoolDataSource初始化完成后，必须立刻调用
setFastConnectionFailoverEnabled(true) - 若用Spring Boot，不能只配
@Configuration或application.yml，得在@PostConstruct方法或InitializingBean.afterPropertiesSet()里手动触发该方法 - 禁用所有TNS层重试逻辑（如
FAILOVER=ON、FAILOVER_MODE块），否则FCF事件清理和TNS轮询会打架，连接可能卡死在坏节点上
服务端FAN+ONS连通性是硬门槛
FCF依赖服务端主动推送FAN事件，不是客户端自己“探测”出来的。缺任何一环，池就收不到DOWN事件，自然不会清理连接。
使用场景：你已确认RAC service启用了FAN（srvctl config service -db <db> -service <svc>显示FAILOVER_TYPE=SELECT），且ONS通路验证通过（onsctl ping -h rac1-vip -p 6200返回success）。
-
tnsnames.ora中service名必须与JDBC连接时指定的SERVICE_NAME完全一致（大小写敏感、无空格） - ONS配置必须指向所有RAC节点的VIP+6200端口，不能只写一个；建议用
ons.nodeList=rac1-vip:6200,rac2-vip:6200格式 - Oracle 11.2.0.1及之前版本存在
db_domain导致FCF失效的bug，12c已修复，但若升级自老版本，仍需检查db_domain是否为空或被意外设值
JDBC URL里别混用TAF参数
TAF（透明应用故障转移）和FCF解决的是不同层面的问题：TAF管长连接中断后的重连行为，FCF管连接池里连接的实时失效感知。两者逻辑冲突，不能共存。
错误配置示例：jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))...(CONNECT_DATA=(SERVICE_NAME=myapp)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(BACKUP=myapp_bk))))——这种URL即使能连上，也会让UCP的FCF失效。
- JDBC URL应极简，只保留基础连接信息，例如：
jdbc:oracle:thin:@myapp，其中myapp是tnsnames.ora里定义的纯service别名 -
tnsnames.ora中该别名下严禁出现任何FAILOVER、FAILOVER_MODE、LOAD_BALANCE字段 - 如果业务真需要查询级自动续查（SELECT-level failover），必须用TAF专用驱动+原生OracleConnection+TAFCallback，而不是走UCP+FCF路径
验证FCF是否真正生效的三个信号
光看代码调用不等于运行时有效。生产环境最容易忽略的是“事件没收到”这个静默失败点。
复杂点在于：FCF生效与否，不体现在日志里，也不抛异常，而是在故障发生时“有没有立刻清理连接”。所以得靠组合验证。
- 启动时检查UCP日志：应有类似
FastConnectionFailover enabled for service myapp的INFO行（需开启oracle.ucp.level=FINE） - 模拟节点宕机后，观察连接池
getNumAvailableConnections()是否快速归零，再回升——回升说明新连接已打到存活节点 - 抓包验证：用
tshark -i any port 6200监听ONS端口，应能看到UDP包在节点宕机后几秒内到达客户端主机
