FAN失效主因是ONS未通、未对、未管，而非配置缺失；需用onsctl ping -h远程测试连通性，确保CRS管理启动ora.ons，禁用TNS相关参数，并显式启用fanEnabled。
fan 失效通常不是因为没配，而是 ons 根本没通、没对、没管——它不响应 fan 事件，客户端就收不到任何 down/up 推送。
onsctl ping 通了，但 FAN 还是不工作
这是最典型的误判。onsctl ping 只验证本地 ONS 进程是否在监听 localport（默认 6113），完全不检测跨节点通信能力。
- 必须用
onsctl ping -h <remote_host> -p <remote_port>逐个测试所有 RAC 节点之间的remoteport（默认 6200）连通性 -
$CRS_HOME/opmn/conf/ons.config中的remoteport必须和racgons add_config注册的端口严格一致 - 所有节点的
localport不能冲突（默认 6113 是安全的，但若改过，需确保各节点不重复） -
$CRS_HOME/log/<host>/client/ons.log出现Connection refused或Failed to connect to remote host就说明 ONS 互通失败
ONS 启动方式错误导致 FAN 事件无法到达客户端
ONS 必须由 Oracle Clusterware 管理启动，手动用 $ORACLE_HOME/bin/onsctl start 启动的是错的实例——它不接入 RAC 内部事件总线。
- 正确启动命令是：
crsctl start resource ora.ons - 确认状态：
crsctl stat res ora.ons -t应显示 ONLINE，且 Target 和 State 都为 ONLINE - 检查进程归属：
ps -ef | grep ons输出中，路径必须含$CRS_HOME，而非$ORACLE_HOME - 禁用
onsctl start类手动操作，否则会与 CRS 管理的 ONS 冲突，造成端口占用或事件丢失
JDBC 连接字符串或 DataSource 配置干扰 FCF 正常触发
FCF 不走 TNS 层逻辑，任何 TNS 相关的 failover/load balance 参数都会破坏事件响应路径。
- 连接字符串里绝不能含
LOAD_BALANCE=ON或FAILOVER=ON，尤其在 SCAN 场景下极易路由到已宕机实例 - 必须显式启用 FAN：
connection.setProperty("oracle.jdbc.fanEnabled", "true")（JDBC）或 UCP 中调用setFastConnectionFailoverEnabled(true) - 服务名（
SERVICE_NAME）必须对应srvctl config service -d <db>中状态为ENABLED的 service，且其FAILOVER_TYPE不能是NONE - 使用 UCP 时，务必关闭隐式缓存：
setImplicitCachingEnabled(false)，否则 FCF 事件无法触发连接清理
客户端首次连接卡顿 30 秒，其实是 ONS 订阅超时
当客户端首次尝试建立 JDBC 连接时，驱动会自动尝试连接 ONS（默认 6200 端口）以订阅 FAN 事件；若防火墙阻断或 ONS 未运行，就会阻塞 30 秒后降级为无 FAN 模式继续建连——这看起来“能连上”，但 FAN 已失效。
- 日志中出现
oracle.simplefan.impl.FanManager configure : attempt to configure ONS in FanManager failed with oracle.ons.NoServersAvailable: Subscription time out就是此现象 - 该问题只发生在首次连接，后续连接复用配置缓存，不再重试 ONS 订阅，所以容易被忽略
- 解决办法只有两个：开放客户端到所有 RAC 节点
remoteport（如 6200）的 TCP 出向连接，或确保ora.ons在所有节点均 ONLINE
真正难排查的从来不是“怎么配”，而是“谁在用哪套 ONS”“事件到底有没有从 RAC 内部发出来”“客户端拿到的到底是哪个配置”。FAN 生效链条太长，漏掉任意一环，都只是安静地沉默，而不是报错。
