FCF生效需服务端FAN开启、ONS通信畅通、客户端正确配置三者缺一不可，仅设oracle.jdbc.fanEnabled=true无效；须检查RAC service状态、ONS连通性、禁用TNS层重试参数，并确保UCP启用setFastConnectionFailoverEnabled(true)及service名精确匹配。
java 应用在 oracle 19c 上启用 fcf（fast connection failover）后，故障切换可从默认的 20–30 秒降至 1–3 秒内完成，但前提是必须绕开 tns 层配置、显式启用事件监听、且服务端 fan 通道真正通路——漏掉任一环，fcf 就是假启用。
为什么 connection.setProperty("oracle.jdbc.fanEnabled", "true") 没效果？
这不是 Java 代码写错了，而是 FCF 的生效依赖整条链路：服务端发得出 FAN 事件 + 客户端收得到 + JDBC 驱动识别并响应。常见断点在前两步。
- 客户端设了
fanEnabled=true，但服务端没开 FAN：检查 RAC service 是否启用ENABLED状态（srvctl config service -d <db></db>），且FAILOVER_TYPE不是NONE - ONS 通信不通：用
onsctl ping -h <remote_host> -p <remote_port></remote_port></remote_host>逐节点验证 ONS 联通性，不能只信本地onsctl ping - JDBC URL 里混了
LOAD_BALANCE=ON或FAILOVER=ON：FCF 和 TNS 层重试互斥，这些参数会干扰事件路由，尤其在 SCAN 场景下导致连接被错误绑定到已宕机实例
tnsnames.ora 里该不该配 FAILOVER=ON？
不该。FCF 完全不走 TNS 的地址列表轮询或重试逻辑，它靠的是服务端推送的 FAN 事件触发连接池自愈。你在 tnsnames.ora 里加 FAILOVER=ON，只会让 JDBC 驱动进入 connect-time failover 模式，和 FCF 并行竞争，反而引发连接混乱或延迟升高。
- FCF 生效时，连接字符串应只保留基础信息，例如：
jdbc:oracle:thin:@myrac-scan:1521/my_service - 所有故障转移行为由 UCP 或 JDBC 连接池内部处理，不是靠地址列表顺序或重试次数
- 如果用了 UCP，务必调用
setFastConnectionFailoverEnabled(true)，而不是只设 JDBC 属性
UCP 连接池启用 FCF 后仍卡住？检查隐式缓存和 service 名匹配
FCF 要求连接池能实时感知连接失效并重建，而隐式缓存（implicit caching）会让旧连接被复用，掩盖真实状态；service 名不匹配则根本收不到对应事件。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 禁用隐式缓存：
connectionPool.setImplicitCachingEnabled(false)，否则 FCF 清理失效连接后，应用仍可能从缓存中取出坏连接 - service 名必须与 RAC 中定义的完全一致（大小写敏感），且该 service 必须通过
srvctl add service添加，并启用-e SELECT或-e SESSION - 确认
oracle.jdbc.fanEnabled是在获取连接前设置的，不是在连接建立后补设——驱动只在初始化阶段读取该属性
observer 和 FCF 是什么关系？
完全无关。observer 是 Data Guard Fast-Start Failover 的组件，负责监控主备库状态并触发数据库级角色切换；FCF 是 RAC 场景下应用层连接池对实例级故障的响应机制，依赖 FAN 事件而非 observer 进程。两者运行在不同栈、解决不同问题，混淆会导致排查方向彻底错误。
立即学习“Java免费学习笔记（深入）”；
FCF 最容易被忽略的点，是它不保证“事务不中断”，只保证“连接快速重建”。SELECT 可重放，DML 仍需应用层配合 Transaction Guard 或 Application Continuity 才能实现断点续传——这点在金融类强一致性场景里，常被当成“已高可用”而埋下隐患。
