使用官方提供的Table API入库报错

[凌若飞霜]

【 使用环境 】生产环境
【 OB or 其他组件 】OCP
【 使用版本 】4.3.5
【问题描述】通过六台（单台配置128C，256G）国产化机器搭建了2-2-2的分布式集群，此前通过正常的SQL语句，使用JDBC连接池可以完成数据入库，使用官方提供的Table API中的ObTableClient的insertorUpdate方法，入库执行大概八九分钟就会开始报一个超时的错误，调整过rpc相关的超时配置，但是效果不明显，还是会运行一段时间就报错，数据表为空表，大概十几个字段，数据总量大概有几千万
【复现路径】问题出现前后相关操作
【附件及日志】后台报错如下：
2026-07-23 11:38:33.354 WARN 99160 — [ analysisFile-2] c.a.o.r.bolt.transport.ObTableRemoting : [Y1D0E585011E8F-000000000000008A] server [192.168.1.12:32882] meet exception: [error code:-4012]
2026-07-23 11:38:33.354 WARN 99160 — [analysisFile-48] c.a.o.r.bolt.transport.ObTableRemoting : [Y1D10285011E8F-0000000000000091] server [192.168.1.12:32882] meet exception: [error code:-6210]
2026-07-23 11:38:33.354 WARN 99160 — [analysisFile-38] c.a.o.r.bolt.transport.ObTableRemoting : [Y1D0A885011E8F-000000000000009C] server [192.168.1.12:32882] meet exception: [error code:-6211]
com.alipay.oceanbase.rpc.exception.ObTableException: [-4012][OB_TIMEOUT][error occur in server][1192.168.1.12:32882][Y1D0E585011E8F-000000000000008A]
at com.alipay.oceanbase.rpc.exception.ExceptionUtil.convertToObTableException(ExceptionUtil.java:97)
at com.alipay.oceanbase.rpc.exception.ExceptionUtil.throwObTableException(ExceptionUtil.java:50)
at com.alipay.oceanbase.rpc.bolt.transport.ObTableRemoting.invokeSync(ObTableRemoting.java:141)
at com.alipay.oceanbase.rpc.table.ObTable.executeWithReconnect(ObTable.java:469)
at com.alipay.oceanbase.rpc.table.ObTable.execute(ObTable.java:447)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.partitionExecute(ObTableClientBatchOpsImpl.java:346)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.executeWithRetries(ObTableClientBatchOpsImpl.java:555)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.executeInternal(ObTableClientBatchOpsImpl.java:618)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.execute(ObTableClientBatchOpsImpl.java:167)
at com.alipay.oceanbase.rpc.ObClusterTableBatchOps.execute(ObClusterTableBatchOps.java:120)
at net.risesoft.service.impl.AnalysisXmlServiceImpl.lambda$testSaveDateBaseBatchMethod$3(AnalysisXmlServiceImpl.java:573)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
com.alipay.oceanbase.rpc.exception.ObTableException: [-6211][OB_TRANS_KILLED][error occur in server][192.168.1.12:32882][Y1D0A885011E8F-000000000000009C]
at com.alipay.oceanbase.rpc.exception.ExceptionUtil.convertToObTableException(ExceptionUtil.java:97)
at com.alipay.oceanbase.rpc.exception.ExceptionUtil.throwObTableException(ExceptionUtil.java:50)
at com.alipay.oceanbase.rpc.bolt.transport.ObTableRemoting.invokeSync(ObTableRemoting.java:141)
at com.alipay.oceanbase.rpc.table.ObTable.executeWithReconnect(ObTable.java:469)
at com.alipay.oceanbase.rpc.table.ObTable.execute(ObTable.java:447)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.partitionExecute(ObTableClientBatchOpsImpl.java:346)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.executeWithRetries(ObTableClientBatchOpsImpl.java:555)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.executeInternal(ObTableClientBatchOpsImpl.java:618)
at com.alipay.oceanbase.rpc.table.ObTableClientBatchOpsImpl.execute(ObTableClientBatchOpsImpl.java:167)
at com.alipay.oceanbase.rpc.ObClusterTableBatchOps.execute(ObClusterTableBatchOps.java:120)
at net.risesoft.service.impl.AnalysisXmlServiceImpl.lambda$testSaveDateBaseBatchMethod$3(AnalysisXmlServiceImpl.java:573)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

以下是连接池配置信息：

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

[论坛小助手]

根据您描述的问题，您的OceanBase数据库在使用Table API的insertOrUpdate方法进行数据入库操作时遇到了超时错误（错误代码：-4012、-6211）。这可能是由于事务执行时间过长导致的。为了帮助进一步诊断这个问题，我建议您利用obdiag工具来进行针对性的日志采集与根因分析。

根因分析

根因分析场景: 事务执行超时报错
根因分析命令: obdiag rca run --scene=transaction_execute_timeout

此命令将帮助我们深入理解为什么事务会在执行过程中超时。请确保运行此命令前准备好相应的错误信息以供输入。

日志采集

日志采集场景: 长事务
日志采集命令: obdiag gather scene run --scene=observer.long_transaction

通过上述命令收集的日志可以帮助我们更好地理解在执行长事务期间发生了什么问题。

完成以上步骤后，请将产生的日志文件打包并提供给我们，以便于我们能够更准确地定位问题原因。

另外，为了更全面地了解情况，请回答以下几个问题：

1. 您能否提供一个具体的SQL语句示例，该语句是在调用insertOrUpdate方法时出现超时问题的？
2. 发生问题的时间点是否有其他大事务正在执行？如果有，请提供这些事务的大致规模和类型。
3. 当前OceanBase集群的配置是怎样的（例如节点数、每个节点的硬件配置等）？
4. 除了提到的rpc相关超时设置外，是否还修改了其他可能影响性能或稳定性的参数？
5. 能否分享完整的错误堆栈信息以及任何可能有助于诊断的日志片段？

这些问题的答案将极大地帮助我们缩小排查范围，并更快找到解决方案。期待您的回复！

附上敏捷诊断工具 obdiag 使用帮助链接

[凌若飞霜]

可是我通过拼接的insert语句，入库相同的数据并不会有超时的问题

[淇铭]

是通过odp连接的 还是直连呢？是不是连接池给的并发太高了 并发批量写入导致的服务端相应慢呀
你查一下 ob_query_timeout这个变量设置的是多少

[耶一耶]

DD

[凌若飞霜]

@淇铭

ob_query_timeout

这个值ob_query_timeout设置了1000秒，因为代码获取到数据后，交给obTableClient的那步实际上是异步执行了，可能速度确实会有点快，但是这期间没有观察到数据库有任何报错信息

[淇铭]

这三个你怎么配置的呢？

1. 异步线程池大小（analysisFile 的 core/max）
2. 单次 batch 大约多少行
3. 大概每秒提交多少个 batch

[凌若飞霜]

异步线程池大小（80/120）
单次batch大约5千-1万
每秒大概提交5个左右吧
通过preparedstatement入库的话，这个配置是可以稳定跑完的

[淇铭]

意思是相比之前 调小了是么？

[凌若飞霜]

是的，单线程跑的话其实还是比较稳定的，但是入库效率偏差，添加线程后我尝试调整了参数的区间值，但是目前都没有完整的入库完成过，我用的CommonsPool写了一个obclient的连接池

[淇铭]

意思按照这个配置 目前没有完整的入库过是么？还是报错么？还是怎么？看你写的可以稳定跑完。
异步线程池大小（80/120）
单次batch大约5千-1万
每秒大概提交5个左右吧
通过preparedstatement入库的话，这个配置是可以稳定跑完的

[凌若飞霜]

@淇铭

preparedstatement

可能我说的不太清楚，我的意思是用的非官方API入库这个线程池配置和数据库集群都没有问题，但是改用官方的API入库就会报我帖子发的那个错，调整线程池大小只会影响报错出现的早晚，始终没有跑完过

[淇铭]

如果你不改官方的table api会报错么？具体改了哪些呢 上面的截图 就是你改的么？
Table API (ObTableClient Batch)的配置也是这样配置么？
异步线程池大小（80/120）
单次batch大约5千-1万
每秒大概提交5个左右吧

通过preparedstatement入库的话 是没有问题的 Table API (ObTableClient Batch)入库 这样配置不行是么？

[wkk2025]

666

[凌若飞霜]

这是所有相关的代码，目前应该可以排除数据库相关配置的问题

[淇铭]

把报错的信息 也发一下

如果是你刚开始发的报错信息的话：
主要原因应该是 高并发批量写入压垮单节点
AnalysisXmlServiceImpl.lambda$testSaveDateBaseBatchMethod$3
→ threadPoolTaskExecutor.execute() // 多线程并发
→ batchOps.execute() // 批量 insertOrUpdate

• 多个 analysisFile-* 线程同时执行批量写入
• 全部打到同一 OB 节点 192.168.1.12:32882
• 单节点 CPU/IO/锁竞争加剧，执行时间拉长，最终触发超时

应用侧高并发大批量写入导致单节点过载，进而触发 RPC 超时（-4012）、事务超时（-6210）和事务被 kill（-6211）。优先做并发控制、批量拆分和超时调优。