FAILOVER_MODE必须位于CONNECT_DATA直接子项，否则Oracle Net静默忽略；Java应用须用tnsnames别名连接并设置TNS_ADMIN，且TYPE与METHOD需配对（如SESSION+BASIC），否则TAF不生效。
FAILOVER_MODE位置错，TAF根本没加载
Oracle Net只在CONNECT_DATA块内识别FAILOVER_MODE，放错位置等于白写。常见错误是把它塞进ADDRESS块或提到DESCRIPTION顶层，驱动静默忽略，连日志都不报——客户端连故障都感知不到，自然卡在重试里。
✅ 正确结构必须是：
(CONNECT_DATA = (SERVICE_NAME = mypdb) (FAILOVER_MODE = (TYPE = SESSION) (METHOD = BASIC)))
❌ 错误示例：
(DESCRIPTION = (FAILOVER_MODE = ...) (ADDRESS_LIST = ...))或
(ADDRESS_LIST = (FAILOVER_MODE = ...) (ADDRESS = ...))
Java应用没走tnsnames别名，TAF压根不触发
JDBC Thin驱动（ojdbc8.jar或ojdbc11.jar）只在解析tnsnames.ora时读取FAILOVER_MODE。用Easy Connect格式直连（如jdbc:oracle:thin:@//rac1-vip:1521/orcl）完全绕过该文件，TAF形同虚设。
必须满足两个条件：
- 连接URL写成
jdbc:oracle:thin:@RACDB（使用tnsnames别名） - 启动JVM前设置
TNS_ADMIN环境变量，指向含tnsnames.ora的目录
Spring Boot中仅配spring.datasource.url=jdbc:oracle:thin:@RACDB不够，TNS_ADMIN未生效则TAF不工作。
RETRIES和DELAY参数设得过大
FAILOVER_MODE里的RETRIES和DELAY控制重试节奏，但常被误设为极端值。例如RETRIES=180、DELAY=5，意味着最长等15分钟才放弃连接——而HTTP接口通常30秒就超时返回504 Gateway Timeout，用户早收不到响应了。
合理值参考：
-
RETRIES=3（最多尝试3次） -
DELAY=1（每次失败后等1秒再试） - 避免设
DELAY大于应用层超时阈值
TYPE与METHOD配对不当，故障时反而中断会话
TYPE决定“故障后做什么”，METHOD决定“什么时候做”，二者不匹配会导致查询失败而非自动续查。
最稳组合是TYPE = SESSION + METHOD = BASIC：实例宕机后重建新会话，SELECT自动重执行，适合DML场景。
别踩这些坑：
-
TYPE = SELECT不是“更强”——它只对已打开游标有效，且需JDBC显式设ResultSet.HOLD_CURSORS_OVER_COMMIT，否则照样抛ORA-03113 -
METHOD = PRECONNECT在ojdbc8+已废弃，设了也不生效，还可能触发ORA-12519（连接数超限）
真正耗时长的地方，往往不是网络或数据库本身，而是配置没生效——TAF没加载、重试策略失控、或类型配对失效。检查v$session里failover_type和failover_method是否非NONE，是最直接的验证方式。
