根本原因是jdbc thin驱动默认忽略taf通知，不解析failover_mode参数，且连接池未清理僵尸连接；须显式启用alt（enablealt=true&altlevel=u）、配置connection-test-query=select 1 from dual及validation-timeout，并确保数据库侧alt_grace_period已设非零值。
java应用在oracle主备切换后无法自动恢复连接，根本原因不是“连不上”，而是jdbc thin驱动默认忽略taf（transparent application failover）通知——即使tnsnames.ora里配了failover_mode，java也不会触发重连逻辑，只会抛出ora-03113后中断。
Oracle TAF在JDBC Thin驱动中默认失效
TAF是Oracle客户端侧的透明故障转移机制，但JDBC Thin驱动从设计上就不支持TAF回调。它不注册监听器事件，也不重试连接或重放事务。哪怕服务端已升主、监听正常、tnsping通，只要原连接断开，Connection对象就进入无效状态，后续调用直接报错。
- Thin驱动不解析
FAILOVER_MODE参数，该配置对它完全无意义 - OCI驱动（需本地
oci.dll）才真正支持TAF，但Java Web应用极少部署OCI环境 - 验证方式：抓包看切换后是否发起新TCP连接——没有，说明驱动没行动
JDBC URL必须显式启用ALT（Application-Level Transparency）
替代TAF的可行路径是GaussDB/Oracle兼容的ALT机制（注意：非Oracle原生，而是国产数据库如GaussDB引入的增强方案）。但前提是数据库实例已开启支持，且JDBC URL中明确激活：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
alt_grace_period参数必须在数据库侧设为非零值（如60），且重启实例生效 - JDBC连接字符串需带
&enableALT=true&altLevel=U，否则ALT不触发 - 仅
targetServerType=master不够，必须叠加ALT参数，否则仍走默认失败路径 - 若用多节点地址（
jdbc:gaussdb://node1,node2,node3/...），ALT才可能选到新主库
连接池未主动探活导致“断一次就永久失效”
即使ALT/TAF配置正确，连接池中的旧连接仍会残留并被复用——它已底层断开，但池子不知道，直到第一次使用时才暴露SQLException。这不是数据库问题，而是连接池健康检查缺失：
- HikariCP需配置
connection-test-query=SELECT 1（Oracle用SELECT 1 FROM DUAL）和validation-timeout - Druid需开启
testWhileIdle=true并设timeBetweenEvictionRunsMillis - 单纯依赖
autoReconnect=true（MySQL特有）对Oracle无效，该参数不被Oracle JDBC识别 - 最稳妥做法：在catch到
SQLException且SQL状态码匹配连接类错误（如08006、08007）时，强制清除当前连接并重试业务逻辑
真正关键的不是“能不能切”，而是“切完之后连接池里还剩多少僵尸连接”——这个细节在多数Oracle高可用文档里被跳过，但恰恰决定业务是否感知到切换。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
