Oracle RAC JDBC连接故障转移如何配置

TAF是唯一保障长连接不中断的客户端Failover机制；需在tnsnames.ora中于CONNECT_DATA内完整配置FAILOVER_MODE（含TYPE、METHOD、BACKUP），JDBC URL须引用该别名并设置TNS_ADMIN，禁用连接池中的LOAD_BALANCE/FAILOVER参数，FCF需正确配置ONS且启用fanEnabled。

Java 应用连接 Oracle RAC 时，默认不启用任何运行时故障转移能力——FAILOVER=ON 只管建连那一刻，实例一挂，ORA-03113 或 Connection reset 立刻报出，连接池里一堆失效连接，应用卡死或重试风暴。真要实现“断了自动切、查询还能续”，必须分层配齐：TNS 层、JDBC 层、连接池层，缺一不可。

tnsnames.ora 中 FAILOVER_MODE 必须显式写全

只写 FAILOVER=ON 或只写 BACKUP=xxx 都无效。Oracle 客户端只认嵌套在 CONNECT_DATA 下的完整块，且以下三项必须同时存在：

1. TYPE：选 SESSION（会话级重连，最常用）或 SELECT（仅对正在执行的查询有效，要求客户端支持游标保持）
2. METHOD：选 BASIC（失败后主动重试），别用 PRECONNECT（启动时预连所有节点，易触发 ORA-12519）
3. BACKUP：必须指向另一个已定义的 TNS 别名（如 RACDB_BACKUP），且该别名自身也得带完整 FAILOVER_MODE

错误示例：(FAILOVER_MODE=(BACKUP=RACDB_BACKUP)) —— 缺 TYPE 和 METHOD，TAF 不生效。

正确结构（推荐闭环式主备）：

(RACDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))(CONNECT_DATA = (SERVICE_NAME = orcl)(FAILOVER_MODE = (TYPE = SESSION)(METHOD = BASIC)(RETRIES = 30)(DELAY = 3)(BACKUP = RACDB_BACKUP)))))(RACDB_BACKUP = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))(CONNECT_DATA = (SERVICE_NAME = orcl)(FAILOVER_MODE = (TYPE = SESSION)(METHOD = BASIC)(RETRIES = 30)(DELAY = 3)(BACKUP = RACDB)))))

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 格式，TAF 完全失效。

1. 正确写法：jdbc:oracle:thin:@RACDB（其中 RACDB 是 tnsnames.ora 里的别名）
2. Java 进程启动前，必须设置 TNS_ADMIN 环境变量指向含 tnsnames.ora 的目录（如 /u01/app/oracle/network/admin）
3. Spring Boot 项目中，spring.datasource.url 不能靠配置文件自动加载 tnsnames.ora，必须确保 JVM 启动时 TNS_ADMIN 已就位

连接池必须禁用 LOAD_BALANCE / FAILOVER 参数

FCF（Fast Connection Failover）和 TNS 层的 LOAD_BALANCE、FAILOVER 逻辑互斥。混用会导致连接被路由到已宕机实例，或 FAN 事件根本进不到连接池。

1. 连接字符串中绝对不要出现：LOAD_BALANCE=yes、FAILOVER=on、FAILOVER_MODE
2. 正确写法（SCAN 场景）：jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=oltp)))
3. UCP 连接池必须调用：pool.setFastConnectionFailoverEnabled(true) 且 pool.setImplicitCachingEnabled(false)
4. HikariCP 或 Tomcat JDBC Pool：获取连接后立即执行 connection.setProperty("oracle.jdbc.fanEnabled", "true")

ONS 配置错误是 FCF 失效最隐蔽的原因

很多人看到 onsctl ping 返回 OK 就以为 ONS 通了，其实它默认只测本机 localhost:6113。真正要验证的是跨节点通信是否可达。

1. 逐节点执行：onsctl ping -h racnode2 -p 6113（替换为目标节点名和端口），所有组合都需返回 OK
2. $CRS_HOME/opmn/conf/ons.config 中的 remoteport 必须与 racgons add_config 注册的端口严格一致；所有节点 localport 不能冲突（默认 6113，改过则需全局统一）
3. ONS 必须由 crsctl start resource ora.ons 启动——手动运行 $ORACLE_HOME/bin/onsctl start 会拉起错误路径下的 ONS，无法接入 RAC 内部事件总线
4. 检查 $CRS_HOME/log/<host>/client/ons.log，出现 Connection refused 或 Failed to connect to remote host 即说明通信断了

FAILOVER_MODE 的 RETRIES 和 DELAY 值设得太小，监听器还没起来就疯狂重试；设得太大，应用会卡住近两分钟才感知故障。真正影响业务连续性的，往往不是配置漏项，而是这些参数没结合 RAC 实际恢复节奏去调优。