聊Oracle迁移，我发现一个很有意思的现象。

大家聊的全是"怎么导数据"。用什么工具导、并行度开多少、网络带宽够不够。好像把这些搞定了，迁移就成功了一大半。

但实际上，真正让人睡不着觉的，从来都不是全量。

全量迁移就是个体力活，数据导过去就行了，慢一点快一点的区别。真正麻烦的，是**全量跑完那一刻才刚开始的事**。

源库还在跑业务，数据还在不停地变。你得把这些增量数据实时抓到目标库里去，然后找一个合适的时间点把业务切过去。窗口就那么短，切不过去就要再等下一个窗口。

我前阵子跟几个做数据库迁移的朋友聊了一圈，发现大家在这个环节遇到的坑出奇地一致。

### 一、先说说大家怎么干这活的

大部分迁移项目的流程都差不多。

第一步，全量。用数据泵导出导入，或者用厂商自带的迁移工具。这步虽然耗时间，但技术含量不高，出问题也好解决。

第二步，增量。这才是真正考验人的地方。全量跑完之后，业务还在继续写，这段时间产生的数据怎么同步过去？方案五花八门：

有的靠应用层双写——业务改代码，同时往两个库写。这方案最稳，但改代码的代价巨大，很多项目根本不敢动。

有的靠时间戳字段轮询——每隔几秒查一次源库，把新数据拉过来。这方案简单，但实时性差，而且对源库有查询压力。

有的靠触发器——源库建触发器，每次变更记录到一个日志表里，然后同步程序去读日志表。这方案实时性还行，但触发器本身对业务有性能影响，运维也麻烦。

有的直接靠数据库自带的同步工具——比如OGG，比如国产库自带的CDC组件。这方案最正统，但要么贵，要么绑死了目标库选型。

还有一类方案，就是基于LogMiner的增量采集。FlinkCDC和Debezium走的就是这条路——通过LogMiner接口从Oracle拉变更数据。这个方案有个好处：不需要改业务代码、不需要建触发器、不需要额外的商业授权（LogMiner本身免费）。

但问题是：**LogMiner这个东西，它不是为迁移场景设计的。**

### 二、LogMiner的坑，全是隐性的

什么叫"不是为迁移场景设计的"？

就是它干别的活没问题，但拿来干增量同步，很多限制就暴露了。

**第一个，性能天花板非常低。**

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

1万条看起来不少对吧？但你要知道，Oracle一个事务可能产生几十上百条redo记录。实际能支撑的业务TPS可能连1000都到不了。

有团队做过一个项目，峰值TPS大概3000多。LogMiner的解析速度一开始还能跟上，到了高峰期就撑不住了。延迟从几秒慢慢涨到几分钟，最后飙到6个多小时。全量已经跑完了，增量追不上，割接窗口就这么错过了。

**更麻烦的是，一旦延迟积累起来，想追平几乎不可能。** 因为业务高峰还在继续，日志还在源源不断地产生，解析线程永远在"处理存量、追不上增量"的状态里挣扎。

**第二个，数据类型支持是个大坑。**

BLOB、CLOB、XMLTYPE这些，LogMiner处理不了。但很多业务表里都有这些类型。

政务项目里这种情况特别多见——各种附件、文书、扫描件都存在数据库里。一碰到这种表，同步链路就断。

有些团队的解决办法是"排除这些字段"——但这种妥协方案，业务方通常接受不了。

**第三个，表名长度限制很要命。**

Oracle 12c开始表名最大长度已经支持128个字符了。但LogMiner只认30个字符以内的表名和列名。

现在的微服务架构，表名带业务域、带版本号，超过30个字符太正常了。你跑着跑着发现某几张表的数据一直没有同步过来，查了半天才知道是表名太长被忽略了。

**第四个，PDB场景更麻烦。**

多租户架构下，如果你在PDB上直接执行LogMiner会有问题，必须在CDB层面配置。而且LogMiner要求必须打开全部PDB才能做增量同步。

生产环境谁会把所有PDB全开？这根本不是一个可接受的方案。

**第五个，大事务直接导致内存爆炸。**

这是最让人头疼的问题。业务方半夜跑了个批量更新，几百万行。LogMiner需要把整个事务的变更都加载到内存里，几百万行的redo可能有好几个GB，PGA直接撑爆，进程崩溃。

有团队遇到这个问题后，把堆内存从540MiB加到了960MiB。结果呢？从25万行撑到35万行，涨了10万行而已。**加内存只是把阈值往上推了一点，根因根本没解决。**

### 三、我们在这个过程里的一些实践

上面这些问题，我们团队在做迁移项目的时候都遇到过。

一个一个去解决？LogMiner是Oracle内核的一部分，闭源的，改不了。

换OGG？授权费用不低，而且对国产库的适配还需要额外开发。

用国产库自带的迁移工具？功能在不断完善，但通常跟特定数据库绑定。你选了A家的数据库就得用A家的工具，选型灵活性受限。

后来我们决定自己写一个日志解析的东西。目标很简单：把Oracle redo log解析出来，不依赖LogMiner，不受它那些限制。

这个东西的核心逻辑就是直接读redo log的二进制格式，自己解析Change Vector，自己还原事务。绕开LogMiner，也绕开XStream。说起来不复杂，但需要把Oracle各个版本的redo格式全部吃透。

我们管这个叫TLA。

目前TLA的Oracle版本已经跑通了。跟基于LogMiner的方案比，有几个比较明显的差异：

第一，没有30字符限制。表名多长都行，不挑。

第二，数据类型支持全面。BLOB、CLOB、XMLTYPE这些都能处理。

第三，流式解析，不缓存事务。不管事务多大，内存占用基本平稳，不会出现大事务撑爆内存的情况。

第四，多线程并行，实测小字段场景能跑到10万条/秒以上。

最关键的一点——**它不依赖任何Oracle闭源组件**。整个解析链路从日志读取到块解析到事务还原，全部自己控制。代码在手上，想改就改。

### 四、说点实在的

如果你正在做Oracle到国产库的迁移，增量同步这个环节有几个判断标准：

第一，你的业务高峰期TPS大概多少？如果超过500，LogMiner方案就要慎重考虑了。不是一定不行，但延迟风险确实存在。

第二，你的表里有没有BLOB、CLOB、XMLTYPE这些类型？有的话，基于LogMiner的方案基本没法用。

第三，你的表名有没有超过30字符的？有的话，又踩一个坑。

第四，你的项目用的是哪个国产库？如果用它的自带迁移工具，要看它底层用的是什么解析方式。有些国产库的迁移工具底层也是依赖LogMiner的，那上面那些问题一样存在。

第五，迁移周期和预算如何？OGG授权费用和周期能否覆盖？

如果这些问题让你觉得心里没底，可以考虑一下TLA这种方案——不依赖LogMiner，纯国产自研，以组件形式存在，可以集成到各种迁移工具里。

目前Oracle版本已经跑通了，后续MySQL、PG和几款国产数据库的支持也在推进中。

欢迎交流。

---

*补充：文中提到的政策时间节点来自公开信创政策文件，具体以各地最新政策为准。性能数据来自内部测试环境，实际效果受硬件配置、数据库版本、日志大小等因素影响。*

大家聊的全是"怎么导数据"。用什么工具导、并行度开多少、网络带宽够不够。好像把这些搞定了，迁移就成功了一大半。

聊Oracle迁移,大家聊的全是"怎么导数据",我发现一个很有意思的现象。

数据库

架构设计

后端

Oracle迁移增量同步是真正难点，LogMiner方案存在性能瓶颈、数据类型限制、表名长度限制、PDB兼容性及大事务内存溢出等隐性坑。建议评估业务TPS、特殊字段类型及表名长度，考虑自研日志解析方案如TLA，支持多线程并行、无限制解析，确保迁移稳定高效。

微服务架构

MySQL

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

聊Oracle迁移,大家聊的全是"怎么导数据",我发现一个很有意思的现象。-腾讯云开发者社区-腾讯云

聊Oracle迁移,大家聊的全是"怎么导数据",我发现一个很有意思的现象。

聊Oracle迁移,大家聊的全是"怎么导数据",我发现一个很有意思的现象。

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐