TAF是唯一保障长连接不中断的客户端Failover机制；Client-Side Connect Time Failover仅作用于初始连接，连接建立后节点故障即断开，对WebLogic/Tomcat等长连接场景无效。
TAF 是唯一能保障长连接不中断的客户端 Failover 机制。Client-Side Connect Time Failover 只在初始建连时生效，连接建立后节点宕机就会直接断开——这对 WebLogic、Tomcat 连接池这类维持长连接的应用毫无用处。
tnsnames.ora 中必须配置 FAILOVER_MODE，不能只靠 FAILOVER=ON
很多人误以为只要写 failover=on 就启用了 taf，其实它只激活 connect time failover。真正让已建立连接自动迁移的，是 failover_mode 子句，且必须嵌套在 connect_data 内部。
-
FAILOVER=ON是默认值，显式写或不写效果一样，它管不了运行中连接 -
FAILOVER_MODE缺失 = 没有 TAF，哪怕实例挂了，JDBC 会话也会抛ORA-03113或ORA-01033并彻底断开 - 常见错误写法：
(FAILOVER_MODE=(TYPE=select))放在DESCRIPTION层级下 —— Oracle 会静默忽略
METHOD=BASIC vs METHOD=PRECONNECT 的实际取舍
选错 METHOD 会导致连接池初始化失败或资源耗尽，不是理论问题，是真实压测中会暴雷的点。
-
METHOD=BASIC：推荐绝大多数场景。连接池首次获取连接时只连一个实例；故障发生时才按DELAY/RETRIES尝试重建到其他实例。延迟可控（比如DELAY=5+RETRIES=3≈ 最多 15 秒不可用），连接数不翻倍 -
METHOD=PRECONNECT：要求连接池创建连接时就同时连所有 RAC 实例（如 4 节点集群 → 单个逻辑连接占 4 个物理连接）。容易触发ORA-12516（TNS:listener could not find available handler）或耗尽PROCESSES参数限额 - WebLogic 默认使用
BASIC，但某些旧版驱动（如 ojdbc6）在 PRECONNECT 下可能卡在 DNS 解析，尤其当 VIP 未正确配进/etc/hosts
TYPE=select 的代价和适用边界
TYPE=select 看似完美（查询中断后自动续查），但它依赖 Oracle 在故障切换时保留游标状态，对底层资源消耗显著高于 TYPE=session。
- 仅对只读长查询有意义：比如报表导出、ETL 抽取等执行时间 >30 秒且结果集大的
SELECT。普通 OLTP 的增删改查一律用TYPE=session - 启用
TYPE=select后，每个 session 的 PGA 会多预留约 2–5 MB 用于保存游标上下文，高并发连接池下内存压力陡增 - 如果应用本身做了查询重试逻辑（比如 Spring RetryTemplate），再配
TYPE=select属于重复兜底，反而增加故障恢复路径复杂度
HOST 名解析失败是 ORA-12545 的最常见原因
即使 tnsping 能通，Java 应用仍报 ORA-12545，90% 是因为客户端没把所有 VIP 和 Public IP 都写进 /etc/hosts（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows）。
- RAC 故障转移过程中，存活实例可能通过 TNS 响应返回原始连接的 Public Hostname（而非 VIP），此时若客户端 hosts 缺少该 hostname 映射，就会解析失败
- 必须同时配置：VIP（如
rac1-vip）、Public IP hostname（如rac1）、SCAN IP（如rac-scan）—— 三者缺一不可 - 不要用纯 IP 地址替代 hostname：Oracle 内部基于 hostname 做 service binding，IP 会导致 TAF 元数据不匹配
TYPE 和 METHOD 的组合直接影响连接池行为、内存占用与故障恢复窗口。最容易被忽略的是 hosts 文件的完整性——它不报错，但会让整个 TAF 配置形同虚设。
