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 下的完整块，且以下三项必须同时存在：
-
TYPE：选SESSION（会话级重连，最常用）或SELECT（仅对正在执行的查询有效，要求客户端支持游标保持） -
METHOD：选BASIC（失败后主动重试），别用PRECONNECT（启动时预连所有节点，易触发ORA-12519） -
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 完全失效。
- 正确写法：
jdbc:oracle:thin:@RACDB（其中RACDB是tnsnames.ora里的别名） - Java 进程启动前，必须设置
TNS_ADMIN环境变量指向含tnsnames.ora的目录（如/u01/app/oracle/network/admin） - Spring Boot 项目中，
spring.datasource.url不能靠配置文件自动加载tnsnames.ora，必须确保 JVM 启动时TNS_ADMIN已就位
连接池必须禁用 LOAD_BALANCE / FAILOVER 参数
FCF（Fast Connection Failover）和 TNS 层的 LOAD_BALANCE、FAILOVER 逻辑互斥。混用会导致连接被路由到已宕机实例，或 FAN 事件根本进不到连接池。
- 连接字符串中绝对不要出现：
LOAD_BALANCE=yes、FAILOVER=on、FAILOVER_MODE - 正确写法（SCAN 场景）：
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=oltp))) - UCP 连接池必须调用：
pool.setFastConnectionFailoverEnabled(true)且pool.setImplicitCachingEnabled(false) - HikariCP 或 Tomcat JDBC Pool：获取连接后立即执行
connection.setProperty("oracle.jdbc.fanEnabled", "true")
ONS 配置错误是 FCF 失效最隐蔽的原因
很多人看到 onsctl ping 返回 OK 就以为 ONS 通了，其实它默认只测本机 localhost:6113。真正要验证的是跨节点通信是否可达。
- 逐节点执行：
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，出现Connection refused或Failed to connect to remote host即说明通信断了
FAILOVER_MODE 的 RETRIES 和 DELAY 值设得太小，监听器还没起来就疯狂重试；设得太大，应用会卡住近两分钟才感知故障。真正影响业务连续性的，往往不是配置漏项，而是这些参数没结合 RAC 实际恢复节奏去调优。
