相同类型宽度的Oracle列间复制数据为何触发ORA-12899错误

问题根因 #

你遇到的报错本质是字符集转换导致的字节长度膨胀，和你的核心复制逻辑无关，常见原因有两个：

• 两个Oracle实例的NLS_CHARACTERSET不一致：Docker部署的非官方Oracle镜像默认字符集通常是WE8MSWIN1252或者US7ASCII，如果你的源库用的是AL32UTF8之类的多字节字符集，当源字段中包含目标字符集不支持的字符时，JDBC会自动将无法识别的字符转义为多字节替代符，原本在源库占100字节的内容，转义后就会超出100字节的限制。
• JDBC自动类型转换引入的额外开销：你用getObject+setObject处理字符串类型字段时，部分版本的Oracle JDBC驱动会做额外的类型校验和转换，可能在字符串末尾引入不可见的控制字符，导致字节长度超出限制。

验证步骤 #

1. 执行以下SQL确认两个库的字符集是否一致：

SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

2. 在代码中增加临时调试逻辑，打印报错行对应MY_COLUMN字段的实际字节长度：

String colValue = data.getString("MY_COLUMN");
// 按目标库字符集计算字节长度，比如目标库是UTF8就用StandardCharsets.UTF_8
System.out.println(colValue.getBytes(StandardCharsets.UTF_8).length);

解决方案 #

• 优先对齐两个库的字符集：修改Docker中Oracle实例的NLS_CHARACTERSET和源库保持一致，从根源避免字符转义问题。
• 如果无法修改目标库字符集，可以将字段定义从VARCHAR2(100 BYTE)调整为VARCHAR2(100 CHAR)，按字符数而非字节数限制长度，适配多字节字符场景。
• 代码层面优化：针对字符串类型字段显式调用getString()和setString()，替代通用的getObject/setObject，避免不必要的类型转换。

内容的提问来源于stack exchange，提问作者George