前言

昨天跟一个老朋友吃饭，聊起他们公司正在搞的数据库国产化迁移，他手里管着一堆库，Oracle、MySQL、SQL Server 啥都有，这一顿操作下来，头发怕是又少了几撮。

听他倒完苦水，我也把我们这边刚做完的一个从 Oracle 到金仓 KES 的项目复盘了一下，征得他同意，把一些真刀真枪的经验分享出来，给大家做个参考。

选型这事儿，真不是看个 PPT 就行的

上头定了要国产化，第一步就是选型。好家伙，一看清单，几十款国产数据库，个个都说自己“自主可控”、“性能卓越”。我们当 DBA 的，心里门儿清，这玩意儿选错了，后面迁移和运维的坑能把自己埋了。

整理了一下目前通过国测的数据库，集中式数据库共 20 个产品，分布式数据库共 11 个产品，供大家参考：

集中式数据库：

分布式数据库：

我们几个 DBA 凑一起，定了几个硬杠杠：

1. 得是“老司机”：市场占有率不能太低，得有大量成熟案例，不能拿我们当小白鼠。
2. “朋友圈”得大：生态工具、周边配套得齐全，不能让我们从零造轮子。
3. “售后”要靠谱：原厂技术支持必须给力，关键时刻不能掉链子，得能快速响应。
4. 别让应用开发“炸锅”：兼容性是最关键的，最好是应用代码能少改甚至不改，不然工作量海了去了，业务部门能跟你急眼。
5. 钱要花在刀刃上：不仅是 License 费用，迁移成本、后续的运维人力成本都得算进去。

翻来覆去地调研、测试、跟各家厂商“斗智斗勇”，最后拍板定了金仓数据库 KES V9。主要是看中它对 Oracle 语法兼容性确实做得不错，而且迁移工具链比较全，感觉能省不少事儿。

迁移路上的那些“坑”，想想都头大

选完型，真正的挑战才刚开始。一想到要动线上的核心库，几个问题就跟噩梦一样绕着我们：

1. 业务怎么不停？ 动不动就几个 T 的库，停机窗口根本要不来，业务停一分钟损失都是真金白银。
2. 应用代码咋办？ 成千上万个存储过程、函数、触发器，难道要开发团队全军覆没，一个个重写？这工作量想想都吓人。
3. 数据一致性怎么保？ 迁移过程中丢一条数据，或者数据对不上，那都是重大事故，谁也担不起。
4. 以后怎么维护？ 我们这帮 Oracle DBA，是不是得从头学起？运维体系、监控告警、备份恢复都得重构，学习成本不低。

当时心里是真没底。好在金仓那边的工程师比较实在，没光给我们画大饼，而是掏出了一套他们称之为 “无中间库不停机” 的方案：说要让我们实现“三低一平”——低成本、低风险、低难度、平滑迁移。

实战复盘：我们是怎么“平滑”过来的

说实话，刚开始我们也是将信将疑。但实际走下来，发现他们这套工具链和方案，确实把我们最担心的几个点给解决了。

第一招：语法兼容，从根源上“减负”

KES V9 这个版本有个挺牛的特性，叫可插拔架构，能同时兼容 Oracle、MySQL 这些主流数据库的语法和存储过程。这意味着啥？意味着我们应用里那些成千上万的 SQL，很有可能一行都不用改！

他们原厂工程师当时拍着胸脯说：“你们先迁，遇到不兼容的 SQL，算我们的，我们数据库来兼容你。” 这话听着提气。

我们拿一个比较复杂的 Oracle 系统试了刀。那个库有：

• 7100 多个对象；
• 786 个包，代码量巨大；
• 5000 多个触发器；
• 好几百个存储过程，逻辑嵌套很深。

你猜怎么着？真就一行代码没改，直接跑通了。 光这一项，就给我们省了至少好几个月的工作量。这是让我们下定决心用他们的最关键一步。

第二招：工具链“傻瓜化”，能偷懒就偷懒

他们提供了一整套工具，什么 KDTS（迁移）、KReplay（流量回放）、KStudio（开发），基本上把评估、迁移、验证的活都包圆了。

部署一套 KES 环境，几分钟就搞定。数据迁移基本是可视化操作，点一点就行。对于我们 DBA 来说，不用去啃那些晦涩的迁移脚本，幸福感大大提升。出了问题，一个电话过去，原厂工程师直接上手支援，这点很关键。

第三招：数据校验，给心里“上道保险”

迁移最怕的就是数据对不上。他们给的方案非常有效，就是在生产环境上做全量回归验证。

具体流程是这样的，我简单描述下：

1. 先在 Oracle 库上打个快照（OD0），然后全量导入到金仓（变成 KD0），两边先比对一次，确保起点一致。
2. 然后，用工具在生产 Oracle 上“录制”一段时间，把所有的 SQL 请求（包括你什么时候登录、执行了啥语句、事务顺序）原原本本地录下来（OS0）。
3. 把这段“录音”（OS0）转换成金仓能听懂的格式（KS0），然后在金仓库上“播放”。
4. “播放”过程中，肯定会遇到一些金仓不认识的“方言”（兼容性问题），这时候就停下来，在金仓数据库上去解决这个问题（通常是他们调整兼容模式或者给个小补丁）。
5. 问题都解决后，再在金仓上完整“播放”一遍。播放完后，再在 Oracle 和金仓上各打一个快照（OD1 和 KD1）。
6. 最后，用比对工具，对 OD1 和 KD1 进行逐行、逐字段的比对，必须 100%一致才算过关。

这个过程虽然耗时，但真是给了我们莫大的信心。相当于在上线前，已经用真实流量把新库“拷”过一遍了，心里踏实。

写在最后

回过头看，这次迁移能成功，选对产品是前提，但用对方法和工具才是关键。金仓这套“无中间库不停机”的方案，确实打在了我们 DBA 的痛点上。

作为亲历者，我的体会是：国产数据库现在真的能用了，尤其是在替代 Oracle 这种传统商业数据库上，已经走出了可行的一条路。别怕，前期 POC 做扎实，迁移工具用熟练，回退方案准备好，这个事儿就能成。

希望我们这点经验，能给还在观望或者正准备上路的兄弟们，提供一点实实在在的参考。有啥问题，欢迎一起交流，咱们 DBA，就是在不断填坑中成长的嘛。