Oracle驱动版本引发ORA-01461批量插入异常排查与解决

Oracle JDBC驱动版本引发ORA-01461批量插入异常排查与解决

问题背景

最近在开发一个数据同步模块时，需要从源数据库视图v_pInfo查询数据，批量插入到目标表AInfo。同步周期为手动触发，按日期范围同步。在测试过程中，批量插入时频繁抛出ORA-01461错误，但逐条插入却能成功。经过一系列排查，最终定位为Oracle JDBC驱动版本问题。本文将详细记录排查过程及解决方案，供遇到类似问题的开发者参考。

环境信息

数据库：Oracle 19c

目标表字段：EVAL_DESC VARCHAR2(500)，其他字段均为常规类型（NUMBER, VARCHAR2, DATE）

源数据量：约4000条/批次

原JDBC驱动：ojdbc11（Spring Boot 3.2.0默认版本）

最终JDBC驱动：ojdbc8 21.7.0.0

现象描述

批量插入异常日志

text 复制代码

2026-03-20 10:24:45.039 ERROR c.l.s.c.AbstractDataSyncService - [AInfo数据] 表 AInfo 同步失败: PreparedStatementCallback; uncategorized SQLException for SQL [INSERT INTO thbi.AInfo ...] SQL state [72000]; error code [1461]; ORA-01461: 只有在将值插入数据类型为 LONG 的列时，才可以绑定一个 LONG 值

逐条插入成功日志

text 复制代码

2026-03-20 10:20:31.825 INFO  c.l.s.c.AbstractDataSyncService - 表 AInfo 同步完成，插入 4162 条数据，耗时: 18342ms

从日志可见，批量插入总是失败，而逐条插入却能完整写入4162条数据。这暗示问题可能出在JDBC批量处理机制上。

排查过程

初步分析：检查表结构与数据长度
首先怀疑是某条记录的EVAL_DESC字段超过了VARCHAR2(500)的限制，导致驱动误以为需要LONG类型。但查询源数据最大长度：

sql 复制代码

SELECT MAX(LENGTHB(eval_desc)) FROM health.v_pInfo;

结果显示最大字节数远小于4000，不会触发VARCHAR2上限。而且逐条插入成功也证实数据本身是合法的。

尝试批量插入降级策略
为了定位问题，我们修改代码：先尝试批量插入，若抛出ORA-01461，则自动降级为该批次逐条插入。结果如下：

第一批1000条批量失败，降级为逐条插入。

降级后的第一条数据就报错：ORA-00001: 违反唯一约束条件。

奇怪的是，明明已经执行了删除操作，为什么还会出现主键冲突？

检查删除逻辑
原删除SQL为：

sql 复制代码

delete from thbi.AInfo
where eval_date >= to_date(:startDate, 'yyyy-mm-dd hh24:mi:ss')
  and eval_date < to_date(:endDate, 'yyyy-mm-dd hh24:mi:ss')+1

而查询SQL也使用了同样的to_date转换。但实际执行时，删除操作只删除了436条，而查询到4162条。说明删除条件未能匹配所有数据，可能是因为eval_date字段在数据库中存储的是DATE类型，与字符串转换后的日期存在细微差异（如时区、时分秒）。导致部分数据未被删除，插入时遇到主键冲突。

修复方案：改为参数化日期绑定，直接传递java.sql.Date对象，避免隐式转换。

java 复制代码

Map<String, Object> deleteParams = new HashMap<>();
deleteParams.put("startDate", java.sql.Date.valueOf(startDate));
deleteParams.put("endDate", java.sql.Date.valueOf(endDate.plusDays(1)));
int deleted = sbhJdbcTemplate.update(deleteSql, deleteParams);

再次测试批量插入，仍然ORA-01461
即使删除准确了，批量插入依然失败，说明问题核心还是驱动本身。

原因分析

查阅资料和Oracle官方文档，ORA-01461通常发生在尝试将超过4000字节的字符串插入VARCHAR2列时。但我们的数据并未超长，逐条插入也能成功，因此怀疑是JDBC驱动在批量处理时对字符串长度的判定逻辑过于敏感。

对比两种驱动：

ojdbc11：针对Oracle 21c及以后版本设计，可能在批量执行时预检字符串长度，将接近4000字节的字符串误判为需要LONG类型绑定，从而报错。
ojdbc8：兼容性更好，对普通VARCHAR2的处理更为稳健，不会触发此异常。

实际上，有社区反馈类似问题：在ojdbc11中，即使字符串长度小于4000，批量插入也可能触发ORA-01461，而降级到ojdbc8则正常。这证实了驱动版本的差异。

解决方案

更换JDBC驱动
将pom.xml中的驱动依赖从ojdbc11改为ojdbc8（版本21.7.0.0）：

xml 复制代码

<dependency>
    <groupId>com.oracle.database.jdbc</groupId>
    <artifactId>ojdbc8</artifactId>
    <version>21.7.0.0</version>
</dependency>

恢复批量插入代码
修改同步方法，恢复高效的批量插入：

java 复制代码

int totalInserted = 0;
int batchSize = 1000;
for (int i = 0; i < dataList.size(); i += batchSize) {
    int end = Math.min(i + batchSize, dataList.size());
    List<Map<String, Object>> batch = dataList.subList(i, end);
    Map<String, Object>[] maps = batch.toArray(new Map[0]);
    int[] results = jdbcTemplate.batchUpdate(insertSql, maps);
    totalInserted += results.length;
    log.info("表 {} 插入第 {} 到 {} 条数据", tableName, i + 1, end);
}
log.info("表 {} 同步完成，插入 {} 条数据", tableName, totalInserted);

最终效果

更换驱动后，批量插入成功，耗时从逐条插入的18秒降至约2秒（4162条数据），性能大幅提升，且无任何异常。

总结与建议

遇到ORA-01461时，先检查数据长度：确保没有字段真的超过VARCHAR2上限（4000字节）。如果数据正常，则考虑驱动问题。
比较批量与逐条插入：若逐条成功而批量失败，基本可判定为驱动或JDBC内部处理逻辑的差异。
选择合适的JDBC驱动版本：对于Oracle 19c及以下，推荐使用ojdbc8系列；对于21c+，可尝试ojdbc11，但需测试批量插入场景。