FCF不是简单开关，而是依赖服务端FAN事件、客户端ONS订阅及连接池协同响应的联动机制；任一环节配置错误（如ONS互通失败、连接属性缺失）均导致fanEnabled设为true也无效。
fcf 不是“开个开关就自动重连”，而是依赖服务端 fan 事件 + 客户端 ons 订阅 + 连接池协同响应的一整套联动机制；配置错任意一环（尤其是 ons 互通或连接属性），fanenabled 设为 true 也完全不生效。
ONS 必须由 CRS 管理，且跨节点 ping 通
很多人用 onsctl ping 看到本地响应就以为 OK，其实只是骗了自己：onsctl ping 默认只测本机 localhost:6113，不验证集群内其他节点能否收发 FAN 事件。
- 必须逐节点执行
onsctl ping -h racnode2 -p 6113（替换为目标节点名和端口），所有组合都返回OK -
$CRS_HOME/opmn/conf/ons.config中的remoteport必须与racgons add_config注册的端口严格一致；所有节点的localport不能冲突（默认 6113，若改过需全局统一） - ONS 必须由
crsctl start resource ora.ons启动——手动运行$ORACLE_HOME/bin/onsctl start会拉起错误路径下的 ONS，无法接入 RAC 内部事件总线 - 检查
$CRS_HOME/log/<host>/client/ons.log</host>，出现Connection refused或Failed to connect to remote host就说明 ONS 通信断了
JDBC 连接字符串里禁用 LOAD_BALANCE 和 FAILOVER
FCF 和 TNS 层的故障转移逻辑互斥。在 SCAN 场景下混用，会导致连接被路由到已宕机实例，或 FAN 事件根本进不到连接池。
- 连接字符串中绝对不要出现
LOAD_BALANCE=yes、FAILOVER=on或FAILOVER_MODE参数 - 正确写法是精简地址列表 + 显式 service 名：
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=oltp))) - 确保该
SERVICE_NAME在 RAC 中处于ENABLED状态（查srvctl config service -d <db></db>），且FAILOVER_TYPE是SELECT或SESSION，不是NONE
UCP 或 HikariCP 中必须显式启用 FCF 并禁用隐式缓存
即使 ONS 和连接串全对，连接池自身若没注册监听或缓存了失效连接，FCF 仍不会触发清理。
- 使用 UCP 时：
pool.setFastConnectionFailoverEnabled(true)必须调用；同时pool.setImplicitCachingEnabled(false)—— 隐式缓存会拦截 FAN 事件，导致连接不释放 - 使用标准 JDBC（如 Tomcat JDBC Pool）时：
connection.setProperty("oracle.jdbc.fanEnabled", "true")必须在获取连接后立即设置，不能靠连接池自动注入 - Spring Boot + Oracle UCP 场景下，
spring.datasource.hikari.data-source-properties.oracle.jdbc.fanEnabled=true无效——Hikari 不透传该属性，必须用HikariConfig.setDataSourceProperties()手动塞入
验证 FCF 是否真在工作，别信日志里的 “Connected”
最可靠的验证方式不是看应用是否连得上，而是模拟单节点宕机后观察连接池行为：是否在 2–5 秒内清掉全部指向该实例的连接，并开始新建连接到存活节点。
- 停掉一个实例：
srvctl stop instance -d <db> -i <inst></inst></db> - 立刻查应用日志：应出现类似
FAN event received: SERVICE_DOWN for service oltp on instance inst1 - 查连接池活跃连接数变化：旧连接应快速归零，新连接数上升，且
netstat -an | grep :1521显示连接目标已切换到另一节点 VIP 或 SCAN IP - 注意：事务中的连接不会被 FCF 强制中断，这是设计使然——FCF 只管空闲连接和新连接建立，运行中事务需应用层自行处理回滚
