根本原因是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中明确激活：
-
alt_grace_period参数必须在数据库侧设为非零值（如60），且重启实例生效 - JDBC连接字符串需带
&enableALT=true&altLevel=U，否则ALT不触发 - 仅
targetServerType=master不够，必须叠加ALT参数，否则仍走默认失败路径 - 若用多节点地址（
jdbc:gaussdb://node1,node2,node3/...），ALT才可能选到新主库
连接池未主动探活导致“断一次就永久失效”
即使ALT/TAF配置正确，连接池中的旧连接仍会残留并被复用——它已底层断开，但池子不知道，直到第一次使用时才暴露SQLException。这不是数据库问题，而是连接池健康检查缺失：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 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免费学习笔记（深入）”；
