Oracle连接中断时executeUpdate()失败应由连接池（如HikariCP）自动重试，而非手动循环；需配置connection-test-query=SELECT 1 FROM DUAL、validation-timeout=3000、max-lifetime比SQLNET.EXPIRE_TIME小至少2分钟，并启用TCP KeepAlive与socketTimeout=60000毫秒。
Oracle连接中断时重试 executeUpdate() 失败怎么办
java应用连oracle时，网络抖动或rac节点切换常导致 sqlexception 抛出，比如 io error: connection reset 或 ora-03113: end-of-file on communication channel。这类错误不是业务逻辑问题，而是瞬时链路故障，直接向上抛异常会让用户看到“操作失败”，但其实重试1–2次大概率成功。
关键不是自己写死 for (int i = 0; i ，而是要识别哪些错误值得重试、哪些必须立即失败（如 <code>ORA-00001: unique constraint violated）。
- 只对网络类、会话中断类错误重试：匹配
SQLException.getSQLState()是否为"08"类（如"08006","08007"），或检查getErrorCode()是否属于 Oracle 的连接/通信错误码（常见有17002,17008,3113,3114） - 避免在事务中盲目重试：如果已执行过
connection.setAutoCommit(false)并调用过executeUpdate()，再次重试前必须先rollback()，否则会报ORA-01086: savepoint 'XXX' does not exist或连接处于不可用状态 - 重试间隔建议用指数退避：第一次等 100ms，第二次 300ms，第三次 800ms，避免雪崩式重连打满Oracle监听器
用 Spring Retry 封装 Oracle DAO 方法是否安全
可以，但要注意 Spring 的 @Retryable 默认不感知 JDBC 连接生命周期——它只是反复调用同一个方法，而底层 Connection 对象可能已在第一次失败后被标记为 closed。直接重试会导致 SQLException: Closed Connection。
正确做法是把「获取连接 + 执行语句」包进一个带重试的原子单元里，而不是只重试 executeUpdate()：
@Retryable(
value = SQLException.class,
include = { SQLException.class },
maxAttempts = 3,
backoff = @Backoff(delay = 100, multiplier = 2.5)
)
public int executeWithRetry(String sql, Object... args) throws SQLException {
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
// 设置参数...
return ps.executeUpdate();
}
}
- 每次重试都新建
Connection，确保状态干净 - 不要在类成员变量里缓存
Connection或PreparedStatement，否则重试时会复用已失效对象 - 若 DAO 已使用
JdbcTemplate，可配合TransactionTemplate+ 自定义RetryCallback，但需显式配置transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW)防止嵌套事务干扰
手动重试时怎么避免重复插入或更新
这是最危险的一环：网络超时后客户端不确定语句是否真正执行，重试可能导致同一笔订单插入两次、库存扣减两次。Oracle 本身不提供“幂等执行”语法，得靠应用层控制。
立即学习“Java免费学习笔记（深入）”；
推荐组合策略：
- 业务主键 + 唯一约束：比如订单表用
order_no作唯一索引，重试插入时捕获ORA-00001后查库确认是否已存在，而不是直接报错 - 带版本号或时间戳的更新：UPDATE 语句加上
WHERE version = ?，执行后检查executeUpdate()返回值是否为 1；若为 0，说明已被其他线程抢先更新，此时可选择重读再试，或抛业务异常 - 慎用
SELECT FOR UPDATE做前置校验：它会在重试前加行锁，但若重试间隔长、锁等待超时，反而引发更多ORA-00060死锁
Oracle RAC 环境下重试要不要切换实例
不需要也不应该由应用层主动切换。Oracle RAC 的透明故障转移（TAF）和 JDBC 的 oracle.jdbc.replay 功能，本意就是让连接自动漂移到存活节点。你手动换 URL（比如从 host1:1521 改成 host2:1521）反而破坏 TAF 行为，还可能绕过 SCAN VIP 负载均衡。
真正该做的是检查 JDBC URL 是否启用高可用特性：
- URL 中包含
?LoadBalance=true&Failover=true（旧驱动）或使用oracle.jdbc.url格式的 RAC 连接串（如jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)(FAILOVER_MODE=(TYPE=SESSION)(METHOD=BASIC))))） - 确认
DataSource配置了testOnBorrow=true和合理validationQuery=SELECT 1 FROM DUAL，这样连接池在借出前能剔除已断开的连接 - 驱动版本至少为
12.2.0.1以上，低版本对 TAF 和 replay 支持不完整，重试时容易卡在 stale connection 上
重试机制本身不能替代连接池健康管理和 Oracle 高可用配置，这两块没配好，再精细的重试逻辑也救不了频繁的连接雪崩。
