聊到Oracle CDC，很多人都遇到过类似的困境。

项目刚开始的时候，需求看起来很简单：把Oracle的增量数据实时采集出来，推给下游。

然后你开始做选型。网上一搜，方案好像不少——免费的LogMiner、开源的Debezium、商业的OGG、Oracle官方的XStream。每个听起来都能用。

但真正开始调研、做POC、往生产环境推的时候，你会发现事情远没有那么简单。

这篇文章就是我们团队做Oracle CDC选型的真实记录。前前后后折腾了几个月，把市面上能看的方案几乎都看了一遍，最后做了一个不太常规的决定。

### 一、需求是什么？

先说清楚我们当时的需求，这样大家评估方案的时候有个参照。

我们要做的是一套数据中台的底层采集管道，从客户的Oracle数据库实时捕获增量变更，推到Kafka供下游消费。几个核心要求：

- **实时性**：延迟控制在秒级，不能出现“越追越慢”的情况
- **数据完整性**：一条都不能丢
- **支持复杂数据类型**：业务表里有BLOB、CLOB、XMLTYPE
- **表名没有长度限制**：客户的微服务架构表名普遍超过30字符
- **对源库影响小**：不能在生产库上增加明显负载
- **成本可控**：预算有限

当时觉得这些要求挺常规的。后来发现，在Oracle CDC这个领域，这些要求加在一起，能把市面上大部分方案都筛掉。

### 二、第一轮调研：LogMiner——免费的午餐，吃不起

LogMiner是Oracle自带的日志分析工具，免费，官方支持，不需要额外装任何东西。

看起来很美对吧？

Oracle官方对LogMiner的定位是“诊断工具”——DBA用来排查重做日志相关问题的。拿诊断工具当CDC用，问题很快就暴露了。

**第一个问题：性能天花板极低。**

LogMiner是单线程解析。Oracle为了不让它拖垮主库，只给它分配一个CPU核心。解析速度大概就在每秒1万条左右。

我们找了一个测试环境模拟业务高峰，TPS大概3000多。LogMiner一开始还能跟上，到了高峰期就撑不住了。延迟从几秒慢慢涨到几分钟，最后飙到了四十多分钟。

更麻烦的是，一旦延迟积累起来，几乎追不平。业务高峰还在继续，日志还在源源不断地产生，解析线程永远在处理存量。

**第二个问题：数据类型支持有限。**

LogMiner不支持BLOB、CLOB、XMLTYPE这些常见类型。我们的业务表里恰好有这些字段，一碰到就抓不到变更。

**第三个问题：表名超过30字符被忽略。**

Oracle 12c开始表名最大长度已经支持128个字符了，但LogMiner只认30个字符以内的。我们客户的表名基本都超过30字符，LogMiner直接忽略不抓，没有任何报错。

**第四个问题：大事务直接OOM。**

几百万行的批量更新，LogMiner需要把整个事务的变更加载到内存里，PGA直接撑爆。

有用户做过测试，把堆内存从540MiB加到960MiB，结果也就从25万行撑到35万行。加了将近一倍的内存，只多撑了10万行。

LogMiner这套方案，我们只用了两周就放弃了。不是配置问题，不是调优问题——是架构天花板就在那里，够不着。

### 三、第二轮调研：Debezium + FlinkCDC——开源的热门组合，坑一个不少

LogMiner不行，那就看开源方案。

Debezium是红帽开源的CDC平台，FlinkCDC的Oracle连接器底层依赖的也是Debezium。社区活跃、文档齐全、用的人多——看起来是个靠谱的选择。

但仔细一看，Debezium的Oracle连接器底层用的还是LogMiner。LogMiner的所有问题，都会原封不动地传递给上层。

我们做了一轮POC，发现了几个之前没预料到的问题：

**第一个问题：延迟波动难以控制。**

Debezium官方自己承认，“使用LogMiner进行Oracle CDC会产生独特的挑战，其权衡取舍与其他同步方式不同”。他们跟社区合作调整了batch size和query fetch size等参数，但效果有限。

在峰值和静默期之间找到平衡，本身就是一件很难的事。

**第二个问题：数据丢失风险。**

GitHub上有人反馈，Debezium Oracle连接器在某些情况下会丢失CDC事件。虽然概率不高，“五十万条里丢一条”，但在我们的场景里，一条都不能丢。

**第三个问题：大事务OOM。**

跟LogMiner一样，Debezium在事务提交之前会把所有变更先缓存到本地内存里。大事务一来，内存直接撑爆。

**第四个问题：数据类型映射错误。**

FlinkCDC的Oracle pipeline连接器在处理`NUMBER(p,0)`且p>=19时会错误映射为BIGINT，导致主键冲突和下游行数据折叠。这种问题在数据同步场景里是致命的。

**第五个问题：CTE查询导致事务卡住。**

有用户发现，当启用`internal.log.mining.use.cte.query`时，已提交的事务会卡在Debezium里不发送。社区有人尝试修复，但问题依然存在。

这些Issue在GitHub上挂了几个月甚至更久，有些到现在还是Open状态。

Debezium是个好项目，但在Oracle这里，它被LogMiner卡住了脖子。底层是闭源的黑盒，上层再怎么优化，天花板就在那里。

### 四、第三轮调研：OGG和XStream——性能好，但用不起

开源方案不行，那就看商业方案。

OGG（Oracle GoldenGate）是Oracle官方的CDC产品，行业标杆，性能好、功能全。

但价格也是真的贵。官方标价每处理器$17,500，而且源端和目标端分别授权。一个16核的源端加一个16核的目标端，光授权就要$56万，每年还要交22%的技术支持费。

我们当时的预算连零头都不够。

XStream是Oracle提供的CDC API，性能比LogMiner好，但使用的前提是必须有OGG授权。而且XStream只是API，上层的事务一致性、检查点恢复、数据加密全要自己实现。

OGG和XStream这条路线，我们连POC都没做——预算这一关就过不去。

### 五、第四轮调研：国产方案——各有各的问题

市面上也有一些国产CDC方案。

但调研下来，发现有的方案基于ROWID实现数据复制。ROWID是物理地址，一旦发生数据重组（reorg、分区变更、表空间迁移），ROWID立即失效。而且基于ROWID的方案无法做双向复制。

有的方案需要在源端插入大量映射表，占用存储、维护复杂，一旦丢失需要大量时间重建。

这些方案我们也没有深入考虑。

### 六、调研结论：没有合适的方案

几轮调研下来，结论有点尴尬：

- **LogMiner**：免费，但性能低、限制多、大事务OOM
- **Debezium/FlinkCDC**：开源、生态好，但底层依赖LogMiner，问题一样不少
- **OGG/XStream**：性能好，但太贵，用不起
- **国产方案**：各有各的问题，有的依赖ROWID，有的需要建映射表

没有一个方案能同时满足我们的所有需求。

### 七、决定自研

调研做到这一步，团队内部开了好几次会。

讨论的结果是：**自己写一个。**

这个决定在当时看起来有点疯狂。Oracle的redo log格式不公开，需要自己逆向、自己分析、自己实现事务还原。市面上几乎没有团队这么做——大部分都是套壳LogMiner。

但我们算了一笔账：如果继续用现有方案，未来几年要持续投入人力去处理延迟、丢数据、OOM这些问题。与其在别人的方案上打补丁，不如从头做一个不受限制的。

我们给自己定了一个目标：**不依赖LogMiner，不依赖任何Oracle闭源组件，直接解析redo log的二进制格式。**

### 八、走出来的路

这条路走了好几年，中间踩了无数坑。

Oracle各个版本的redo格式有细微差异，需要逐一适配。Change Vector的操作码有150多种，每种都要处理。大事务可能跨多个日志文件，需要自己实现跨文件关联。RAC环境下多个实例的日志需要按全局SCN排序。

但走通之后，效果确实不一样。

没有30字符表名限制。BLOB、CLOB、XMLTYPE这些复杂类型都能处理。流式解析不缓存整个事务，大事务不会OOM。多线程并行，性能比单线程的LogMiner高一个数量级。

整个解析链路从日志读取到块解析到事务还原，全部自己控制。遇到问题自己改代码就行，不用等社区排期，不用等Oracle补丁。

我们管这套东西叫TLA。目前Oracle版本已经跑通了，后续MySQL、PG和国产数据库的支持也在推进中。

### 九、说句实在话

回过头看，当初决定自研的时候，很多人觉得我们疯了——放着现成的开源方案不用，非要自己从零开始啃Oracle的二进制日志。

但做了几年之后回头看，这个决定是对的。

不是因为我们比别人聪明，而是因为**在Oracle CDC这个领域，套壳方案的天花板就在那里**。LogMiner是闭源的、黑盒的、你动不了的。你在外面再怎么优化，也改不了里面的问题。

自研这条路很难走，但走通了就不受任何人限制。

如果你也在做Oracle CDC的选型，也在被延迟、丢数据、OOM这些问题困扰——希望我们的经历能给你一些参考。

欢迎交流。

项目刚开始的时候，需求看起来很简单：把Oracle的增量数据实时采集出来，推给下游。

调研了市面上所有Oracle CDC方案后，我们决定自研

数据库

开发工具

架构设计

**Oracle CDC选型避坑指南：LogMiner性能天花板低、大事务OOM，Debezium依赖LogMiner存丢数据风险，OGG/XStream成本过高。团队实测后自研TLA，直接解析redo log，无表名限制、支持复杂类型、性能高一个量级，为实时数据采集提供高性价比方案。**

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

调研了市面上所有Oracle CDC方案后，我们决定自研-腾讯云开发者社区-腾讯云

调研了市面上所有Oracle CDC方案后，我们决定自研

调研了市面上所有Oracle CDC方案后，我们决定自研

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐