Java 不参与 Oracle Data Guard 自动故障转移（FSFO）决策或执行，仅能通过配置 TAF 和 UCP 感知切换并快速恢复连接；FSFO 完全由数据库层的 Data Guard Broker、observer 进程及重做传输机制控制。
java 本身不参与 oracle data guard 的自动故障转移（fsfo）决策或执行——这个过程完全由 oracle 数据库层的 data guard broker、observer 进程和底层重做传输机制控制。java 应用能做的，是**感知切换完成后的连接变化，并快速恢复业务连接**，而不是“实现”切换本身。
为什么 Java 不能触发或控制 FSFO
Fast-Start Failover 是数据库内核级能力，依赖：dgmgrl 配置、DMON 后台进程、StaticConnectIdentifier 解析、observer 持续在线等。Java 连接池（如 HikariCP、UCP）没有权限调用 ENABLE FAST_START FAILOVER 或监听 DG 状态变更事件。试图在 Java 中“模拟”切换逻辑（比如轮询 v$database.database_role）既不可靠，也违背 Oracle 官方架构设计。
Java 应用必须配置透明应用故障转移（TAF）
这是 Java 接入 FSFO 生效的关键前提。否则即使数据库秒级切换成功，应用仍会报 IO Error: Connection reset 或卡在旧连接上。
- 使用 Oracle UCP（Universal Connection Pool）而非基础 JDBC Driver：UCP 原生支持 TAF 和 Fast Connection Failover（FCF）
- 连接字符串中必须启用 TAF：
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl_svc)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=3)(DELAY=5)))) - 确保
orcl_svc是通过srvctl add service创建的 RAC-aware 服务（即使单实例也建议配），且已注册到监听器（lsnrctl status可见） - 禁用连接池的“testOnBorrow”类健康检查——它会干扰 TAF 的连接重建流程
常见错误：应用层重连失败的三个典型原因
FSFO 成功后，Java 应用仍报错或长时间无响应，往往不是数据库问题，而是连接层配置失当：
-
java.sql.SQLRecoverableException: IO Error: Connection reset：未启用 TAF，JDBC 尝试复用已失效 socket - 连接池返回 stale connection：未配置 UCP 的
setFastConnectionFailoverEnabled(true)，导致 FCF 事件未被消费 - 新主库监听未就绪：FSFO 切换后，新主库需几秒启动监听并注册服务；应用若在
STATUS=READY前发起连接，会触发超时而非自动重试——此时应加大连接池的connection-timeout至 30s 以上
验证 Java 是否真正适配 FSFO 的实操步骤
不要只看日志是否报错，要验证端到端行为：
立即学习“Java免费学习笔记（深入）”；
- 在 observer 主机执行
tail -f $ORACLE_HOME/rdbms/log/drc*.log，确认 FSFO 触发时间点（如 “Initiating failover to database ‘standby_db’”） - 在 Java 应用侧开启 UCP 日志：
ucp.setLogLevel(Level.FINEST)，搜索关键词FCF_EVENT和Connection closed due to FCF - 用
netstat -an | grep :1521在应用服务器上确认旧连接是否被主动关闭，新连接是否建立到新主库 IP - 关键指标：从 observer 日志中 FSFO 开始时间，到 Java 日志中第一条
FCF_EVENT: STATE_UP的延迟，应 ≤ 60 秒（含监听注册+连接池重建）
最易被忽略的是：FSFO 切换后，新主库的 tnsnames.ora 中 StaticConnectIdentifier 必须指向自身（即新主库的监听地址），否则 observer 下次心跳检测会失败，导致后续故障无法再触发自动切换。这个值不会自动更新，必须在切换前通过 Broker 配置固化。
