java连接oracle rac默认不启用taf，仅failover=on仅支持建连时故障转移；真正实现会话中透明切换必须显式配置failover_mode（含type、method、retries、delay），且需tnsnames.ora生效、jdbc url引用别名、关闭fan、确保vip可解析。
java 应用连接 oracle rac 时，默认不启用 taf（transparent application failover），只靠 failover=on 无法在连接建立后自动切实例——必须显式配置 failover_mode，且驱动、url、tnsnames 需协同生效。
tnsnames.ora 中必须显式写全 FAILOVER_MODE，不能只依赖 FAILOVER=ON
很多人以为只要 tnsnames.ora 里有多个 ADDRESS 就能“自动故障转移”，其实那只是 Connect-time Failover，只管建连那一刻。Java 程序一旦连上某个实例，后续该实例宕机，连接就直接报 IO Error: Connection reset 或 ORA-03113: end-of-file on communication channel，不会自动重连。
真正要实现连接建立后的透明切换（TAF），必须在 tnsnames.ora 的 DESCRIPTION 下添加完整 FAILOVER_MODE 块：
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = orcl)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 3)
(DELAY = 5)
)
)
)
-
TYPE = SELECT才能让正在执行的查询在故障后继续返回剩余结果；TYPE = SESSION只重连，不续查 -
METHOD = BASIC是主流选择，PRECONNECT会为每个实例都建连接，Java 连接池（如 HikariCP）容易因重复连接触发资源争用或ORA-12519 -
RETRIES和DELAY控制重试节奏，设太小（如DELAY=1）可能被监听器限流，设太大（如DELAY=30）会导致应用卡顿明显
Java JDBC URL 必须指向 tnsnames 别名，不能用 Easy Connect 格式
Oracle JDBC 驱动（ojdbc8.jar 或 ojdbc11.jar）只有在解析 tnsnames.ora 时才会读取 FAILOVER_MODE。如果 JDBC URL 写成 jdbc:oracle:thin:@//rac1-vip:1521/orcl 这类 Easy Connect 形式，FAILOVER_MODE 完全无效，TAF 不启动。
- 正确做法：把上面那段 tnsnames 配置存为
$ORACLE_HOME/network/admin/tnsnames.ora，JDBC URL 写成jdbc:oracle:thin:@RAC（其中RAC是 tnsnames 里的别名） - Java 进程启动前，确保设置了
TNS_ADMIN环境变量指向含 tnsnames.ora 的目录，否则驱动找不到文件 - Spring Boot 项目中，不能靠
spring.datasource.url直接传 tnsnames 别名——需配合oracle.jdbc.fanEnabled=false（见下一条）避免冲突
ojdbc8+ 默认启用 FAN，但会干扰 TAF 行为，需手动关闭
Oracle 18c/19c 的 ojdbc8.jar 默认开启 Fast Application Notification（FAN），它通过订阅 RAC 的服务状态事件来主动感知节点变化。但 FAN 和 TAF 在 Java 层存在竞争：FAN 触发连接池驱逐连接时，TAF 的重连逻辑可能被跳过，导致连接直接抛异常而不是透明切换。
- 解决方法是在 JDBC URL 后追加参数：
jdbc:oracle:thin:@RAC?oracle.jdbc.fanEnabled=false - 或者在 DataSource 初始化时设置属性：
props.setProperty("oracle.jdbc.fanEnabled", "false"); - 不关 FAN 的典型现象：节点宕机后，HikariCP 日志出现
Connection marked as failed，但应用线程仍卡在executeQuery()不返回，也不重试——这不是 TAF 失效，是 FAN 和连接池协作异常
验证 TAF 是否真生效，不能只看连接是否成功
很多测试停掉一个节点后 Java 还能连上，就认为“Failover OK”，这是错觉。TAF 的核心价值是连接已建立、SQL 正在执行时的故障响应。必须模拟运行中故障：
- 起一个长查询（如
SELECT * FROM big_table ORDER BY dbms_random.value），让它持续返回结果几秒 - 在结果返回中途，用
srvctl stop instance -i orcl1 -d orcl干掉当前连接所在的实例 - 观察 Java 线程：若用
TYPE=SELECT，应看到结果集继续返回（中间可能有 5–10 秒停顿）；若用TYPE=SESSION，会抛SQLException且需应用层捕获重试 - 关键检查点：抓包看客户端是否向第二个 VIP 发起新连接；查数据库
v$session确认会话已迁移到另一节点
最容易被忽略的是：tnsnames.ora 中的 VIP 主机名必须能在 Java 进程所在机器上 nslookup 解析成功，否则地址列表直接被跳过，FAILOVER_MODE 形同虚设。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
