聊到Oracle迁移，增量同步这关，很多人第一反应都是那两座绕不开的大山：一个是慢到让人没脾气的LogMiner，一个是贵到让人肉疼的OGG。

聊到Oracle迁移，增量同步这关，很多人第一反应都是那两座绕不开的大山：一个是慢到让人没脾气的LogMiner，一个是贵到让人肉疼的OGG。

之前聊得比较多的是OGG太贵，给高端市场盖了个天花板。今天想换个角度，重点聊聊另一头——基于LogMiner的方案（比如FlinkCDC、Debezium），到底有多“坑”？

很多项目一开始选型，觉得LogMiner免费、开源方案成熟，就上了。结果跑到一半发现，这哪是省钱，分明是给自己挖了个填不完的坑。

FlinkCDC和Debezium用的LogMiner，到底慢在哪？

先说一个关键数据：单线程LogMiner的解析速度峰值，大概只有1.2万条/秒。什么概念？一个中等规模的业务系统，高峰期每秒产生的变更可能都不止这个数。日志生成速度超过解析速度，延迟就会像滚雪球一样越滚越大。

有团队遇到过更极端的情况——每小时产生60GB归档日志，延迟直接跑到小时级别。Flink CDC官方的Issue里，有人反映SCN增长过快的时候，LogMiner根本追不上最新数据。GitHub上还有用户反馈，更新大量数据时直接报 OutOfMemoryError: Java heap space。社区里也有人在问：“修改表中一条数据要等几个小时是为什么？”——答案是LogMiner本身就有延迟。

InfoQ上有一篇文章说得比较直接：按照Oracle官方的说法，每秒钟几百个事务时就会遇到较大的延迟和内存问题。Debezium框架由于其实现，实际解析速度比这个数值更低。

慢也就算了，关键是它还会跟主库抢资源。LogMiner运行在数据库内部，提取数据时可能产生锁竞争。CPU和内存消耗都不小。官方给LogMiner的限制是单个进程CPU占用不超过1核，本来就是“带着镣铐跳舞”——又想让它干活，又怕它把主库拖垮。

慢之外，还有一堆硬限制

如果说性能问题还能靠加硬件、做优化勉强撑一撑，那下面这些限制就是根本绕不过去的坎。

表名和列名不能超过30个字符。Oracle 12c开始表名最大长度已经扩展到128个字符了，但LogMiner就是认死理——超过30个字符的表，直接忽略不抓。你想想，现在的业务系统，谁敢保证所有表名都在30个字符以内？迁移做到一半报错说表名太长，这种事真的发生过。

大量数据类型不支持。 LogMiner官方文档明确列了一堆不支持的数据类型和表存储属性。BLOB、CLOB、XMLTYPE这些复杂类型，Debezium或Flink根本支持不了。JDBC不支持直接读取CLOB字段数据。Debezium官方也承认，新功能如BOOLEAN、Vector等数据类型的支持，取决于LogMiner和XStream是否提供。说白了——LogMiner不支持，上层工具再怎么折腾也没用。

长事务和回滚处理是硬伤。 一个事务可能跨越多轮LogMiner解析窗口，一条长SQL可能被拆成多段，BLOB更新可能先记录locator再分多次写入，最后还可能回滚。只要事务前半段的关键上下文丢了，数据一致性就出问题。

RAC和PDB支持有隐患。 多租户架构下，如果在PDB上直接执行LogMiner会有问题，必须在CDB层面配置。RAC环境下日志切换时可能出现miss log file异常。生产环境的标配架构，到LogMiner这儿全成了麻烦。

一个很现实的对比

我们把基于LogMiner的方案（FlinkCDC/Debezium）和TLA放在一起看：

对比维度	FlinkCDC/Debezium（LogMiner）	TLA
解析方式	调用LogMiner接口，单线程解析	直接解析redo log二进制，多线程并行
性能上限	~1.2万条/秒	实测10.8万条/秒
高日志量场景	60GB/小时延迟达小时级	流式解析，延迟秒级
表名/列名限制	≤30字符，超长被忽略	无限制
BLOB/CLOB/XMLTYPE	不支持或支持有限	支持
长事务/回滚	易丢失上下文，一致性风险	事务语义完整还原
对主库影响	运行在库内，消耗CPU/内存，可能锁竞争	可异机部署，对源库几乎无影响
RAC/PDB	配置复杂，存在隐患	完整支持

TLA直接读取redo log的二进制格式，不调用LogMiner也不依赖任何Oracle组件。单进程多线程解析，实测小字段场景能跑到10.8万条/秒。LogMiner上限1万条出头，这个差距是数量级的。

再说说国产化的意义

说实话，技术选型到最后往往不只是一个技术问题。

现在很多行业在推信创，数据库国产化替代是大趋势。但CDC这块一直是个短板——开源方案绑在LogMiner上，性能和限制都摆在那里；商业方案OGG能力强但太贵，而且对国产环境的支持进度也跟不上国内企业的节奏。

TLA的定位其实很清晰：它是一个纯国产自研的日志解析组件，不依赖任何国外商业软件，源码完全可控。

这意味着什么？

第一，不受制于人。 不用担心Oracle版本升级导致LogMiner行为变化、不用担心OGG授权政策调整、不用担心某天被“卡脖子”。出了问题自己改，不用等国外厂商的补丁。

第二，可以深度定制。 TLA是组件形态，可以嵌入到任何数据平台、ETL工具、迁移方案里。需要适配国产数据库？改代码就行。需要支持特定的数据类型？加解析逻辑就行。这种灵活度，是套壳LogMiner的方案给不了的。

第三，成本可控。 没有OGG那种按处理器收费的授权模式，也没有LogMiner那种“免费但跑不动”的隐性成本。

说点实在的

FlinkCDC和Debezium都是优秀的开源项目，在MySQL、PG等数据库的CDC上表现很好。但在Oracle这里，它们被LogMiner卡住了脖子——不是它们不想做得更好，是LogMiner的天花板就这么高。

LogMiner的设计初衷是诊断工具，不是为持续高吞吐的CDC而生的。把它硬生生当成同步工具来用，性能和限制的问题迟早会暴露。

TLA做的事其实很简单——绕过LogMiner，直接啃二进制日志。听起来不复杂，但要把Oracle各个版本的redo log格式吃透、把事务语义完整还原、把性能做到比LogMiner高一个数量级，背后是实打实的底层研发投入。

如果你正在做Oracle迁移，正在被FlinkCDC或Debezium的延迟和限制折磨，或者正在OGG的报价前犹豫——TLA提供了一个额外的选择：纯国产、组件化、可定制、不依赖LogMiner。

欢迎交流。

---

补充：文中提到的性能数据来自内部测试环境，实际效果受硬件配置、数据库版本、日志大小等因素影响，建议按实际场景验证。