当你把数据同步到 OceanBase Oracle 模式时往往会遇到令人抓狂的慢写：即便开启了 JD娱乐 batch、拉满并发。监控里的增量 RPS 长期停留在几十上百，单次写入耗时飙升至二十多万毫秒，写入队列一路堆积。你已经排查过配置，却发现瓶颈根本不在参数，而是被忽略的细节——JD娱乐 batch 调用成功。并不等同于数据库服务端真正做了集合化执行。

batch 开了为什么写入还是慢？

拖慢 OceanBase Oracle 写入的，通常有两个场景：

再看场景一。batch MERGE 在服务端“失效”

数据同步到 OceanBase Oracle 模式时遇到主键冲突通常要用 MERGE INTO…USING ，ON … 实现“存在则更新、不存在则插入”。客户端代码看起来规规矩矩：

ps.addBatch;ps.executeBatch;

但 addBatch/executeBatch 只代表 JD娱乐 把请求批量发出去了不代表服务端把多行 成一条集合 SQL。按理说，在 OceanBase Oracle 模式下实际排查。经常会看到服务端仍在执行 N 次单行 MERGE——说白了batch 在服务端层面“失效”了。

至于表现到监控上，

• 增量 RPS 长期在几十上下几乎没有有效吞吐
• 执行写入耗时峰值约 200 000 ms
• 写入队列等待时间超 1 000 000 000 ns。数据基本堵在队列里

至于场景二，高频 INSERT/UPDATE/DELETE 把 batch 切碎

增量同步的数据按源端事务和日志事件到达。说起来，哪怕同一张表短时间内涌入大量数据。只要事件类型不停切换：

INSERT → UPDATE → DELETE → UPDATE → INSERT…

普通批量写入只能按操作类型分开执行。本可以合并的一组同表数据，被切成大量只有几行、几十行的小批次。说到直接后果，

• 目标表被反复 INSERT / UPDATE / DELETE / MERGE，同一主键短时间内被多次探测和修改
• executeBatch 调用次数暴增，小事务刷盘与提交开销叠加
• BATCH 越碎，参数绑定和网络交互的固定成本占比越高

根因这方面。batch API 成功 ≠ 服务端集合执行

Many people think that calling executeBatch automatically means batch write on server side. In reality,JD娱乐 batch solves only client‑to‑server network round‑trip cost;it does not guarantee that server will merge multiple DML statements into a single set‑based execution plan.

This problem is especially pronounced in OceanBase Oracle mode with MERGE. The client sends a batched MERGE,but server may still execute it as N individual MERGEs—completely forfeiting benefits of set‑based execution.

The bottom line: you cannot just crank up concurrency;you must force server to truly perform set‑based operations.

说到解法。CloudCanal Staging Merge

The Staging Merge approach uses one unified path to solve both problems:

1. BATCH WRITE TO STAGING TABLE: First insert entire batch into a staging temporary table using a single bulk INSERT.
2. SINGLE SET‑BASED UPDATE/DELETE ON TARGET: Then apply one or two collection SQL statements against target table using data from staging table.
3. CLEANUP: Commit and let session cleanup remove staging data automatically.

This strategy bypasses reliance on server‑side batch optimization by explicitly performing set‑based updates via temporary tables.

为什么用临时表，而不是直接改目标表？

• AWS/GTT兼容性： OceanBase/Oracle 的 GLOBAL TEMPORARY TABLE天然适合作为 source 数据。
• SCOPE & PRIVACY： 结构全局可见。但数据 session 私有，不同连接互不干扰。
• AUTOMATIC CLEANUP：  确保 commit 后自动清理 staging 数据。其实，

开启方式与适用范围

• useStagingMerge: 设置为 true 开启临时表合并模式。
• stagingSchema: 指定临时表所在 schema，以便统一管理。

This mode can be enabled during both full load and incremental phases for any OceanBase for Oracle target.

说到效果，RPS 与耗时提高实测

这篇文章提供的是 **OceanBase for Oracle** 的真实实验结果。再看一样的环境，阿里云 ECS 8C16G、宽表结构、writeParallel 配置、increBatchSize 设置。无 CPU 或内存瓶颈，

OB Oracle Batch MERGE 失效场景对比

• 调整前 RPS：-
`
• 调整后 RPS ： -
` `` `
• 单次写入耗时 ： - 从约 **200 000 ms** 降至 **约 25 000 ms** ​` `` `
• 队列等待时间 ： - 从> 1 s 降至几毫秒级别。不再堆积​` `` ` ` ` ` `` ``

  高频 I/U/D 混合场景方法

  原本会被切成大量小批次的混合 I/U/D，现在通过 Staging Merge 可先在内存中按主键压缩最终状态，再一次性通过两条集合 SQL 完成落库：
  • 一条集合 DELETE 删除所有需要删除的主键；
  • 一条集合 MERGE 写或更新剩余记录。不过，

  这省去目标表频繁探测和小事务提交的成本。以 MySQL → OceanBase Oracle 为例，该机制一样适用于纯 Oracle 目标端。按理说，

  混合 DML 如何收敛成两条集合 SQL

  原始事件序列	压缩后目标动作
  INSERT UPDATE UPDATE	仅更新一次
  UPDATE UPDATE DELETE	仅删除一次
  DELETE INSERT UPDATE	先删除后插/更新一次
  INSERT DELETE	无任何操作

  适用场景与代价

  收益：

  • 高冲突批量写入性能更稳健；• 大幅减少服务端单行 MERGE 执行次数；• 高频 I/U/D 混合时可将多个小批次收敛为少数集合 DML；• 宽表场景下比单行 MERGE 更友好且更易 ​

  从代价来看。

  

            

  • 自动在目标库指定 schema 下创建临时表，无需手动管理；• 对于极大规模的数据集，需要足够硬盘空间支持临时存储；• 在极低延迟需求下需要额外关注回收策略以避免长时间占用资源。话说回来，

  快速开始

  如果你正在做 OceanBase for Oracle方向的数据同步。而且遇到了差不多写入瓶颈，可以考虑升级到 CloudCanal v6.x 并开启 useStagingMerge 参数。

  老使用者一键升级到 v6.x

  curl -fsSL https://tgzdownload.clougence.com/support/upgradeondocker.sh | bash -s -- . ./cc_home\
  

  新使用者一键安装

  Your installation directory is “./cc_home”. Adjust if necessary. After installation open your browser at http:/// to access console. Refer to Installation & Upgrade Guides for full steps.

  如果部署或使用中遇到任何问题。请随时联系技术支持，我们将竭诚为您服务。