FAN生效需服务端推送事件、客户端ONS正确接收、JDBC显式启用三者同时满足；仅srvctl设-q TRUE不够，须确认srvctl config service输出含Server Side Failover: YES且Failover type为SELECT或SESSION，DBA_SERVICES中ENABLED为YES，ONS双向ping通6200端口，JDBC禁用LOAD_BALANCE=ON等干扰参数并启用oracle.jdbc.fanEnabled。
FAN 不是设个参数就生效的，必须服务端推送事件 + 客户端 ONS 正确接收 + JDBC 显式启用三者同时满足，缺一不可。
检查数据库服务是否真正启用了 FAN
只在 srvctl 里设了 -q TRUE 不够，还要确认 service 状态和 FAILOVER_TYPE：
- 执行
srvctl config service -d <db>，输出中必须含Server Side Failover: YES且Failover type: SELECT或SESSION（不能是NONE） - 查服务当前状态：
SELECT NAME, FAILOVER_TYPE, FAILOVER_METHOD, ENABLED FROM DBA_SERVICES WHERE NAME = '<service_name>';，ENABLED必须为YES -
srvctl modify service -d <db> -s <service> -q TRUE -m BASIC -z 3 -w 5是常用组合，但修改后需srvctl stop service再start才真正生效
验证跨节点 ONS 通信是否真实连通
onsctl ping 成功 ≠ FAN 可用。默认端口是 6200（不是 6113），且 CRS 管理的 ONS 才能收 RAC 内部事件：
- 所有 RAC 节点上执行：
crsctl start resource ora.ons（禁用手动启$ORACLE_HOME/bin/onsctl start） - 从 rac1 上执行：
onsctl ping -h rac2 -p 6200；再从 rac2 上反向 ping rac1 —— 必须双向成功 - 检查日志：
$CRS_HOME/log/<host>/client/ons.log，若出现Connection refused或Failed to connect to remote host，说明网络或防火墙阻断 -
$CRS_HOME/opmn/conf/ons.config中的remoteport=6200必须与racgons add_config注册端口一致，且各节点localport不能重复
JDBC 连接池必须显式启用 FCF，且禁用干扰参数
只设 connection.setProperty("oracle.jdbc.fanEnabled", "true") 还不够，连接池行为受多个隐式条件控制：
- 连接字符串中严禁出现
LOAD_BALANCE=ON或FAILOVER=ON—— 它们会绕过 FCF 的事件响应路径，尤其在 SCAN 场景下导致请求发往已宕机实例 - 必须使用
SERVICE_NAME（非 SID），且该 service 必须是上面验证过的已启用 FAN 的那个 - 若用 UCP：
pool.setFastConnectionFailoverEnabled(true)+pool.setImplicitCachingEnabled(false)（否则 FCF 触发后旧连接不被清理） - 连接 URL 推荐用 SCAN：
jdbc:oracle:thin:@scan-host:1521/ORCL，避免写死 VIP 或单节点地址
为什么配了 SCAN + TAF 还是等 30 秒才报错
SCAN 解决的是地址发现，TAF（TNS 层）解决的是建连时重试，两者都不感知运行时实例故障。FAN 是唯一能让连接池“立刻知道”实例挂了的机制：
- TAF 的
FAILOVER_MODE在 JDBC Thin 驱动中基本无效，除非你用tnsnames.ora+TNS_ADMIN环境变量 + 别名 URL，且驱动版本、配置位置、解析时机都严丝合缝 - FAN 事件是异步广播的，客户端 ONS 收到
DOWN后，连接池会在毫秒级内标记对应实例的连接为失效，并拒绝新请求路由过去 - 最易忽略的一点：WebLogic 的 GridLink 数据源虽原生支持 FAN，但必须在控制台里明确勾选 “Enable Fast Connection Failover”，且 ONS 配置指向正确的 remote hosts 和 port（默认 6200）
