一、替换项目里，迁移是块最硬的骨头
聊到达梦VS金仓，很多人第一反应是比参数。并发能力多少，TPC-C 跑分多高，集群架构谁更花哨。这些当然要比，但说实话，对真正在做国产化替换的人来说，这些都不是最疼的地方。
最疼的是迁移。
替换项目有个特点，数据库本身的钱和工期都是一次性的，迁移才是那个能把整个项目拖进泥潭的阶段。一套跑了十年的老系统，几千个数据库对象，存储过程里塞满了只有原作者才看得懂的逻辑，应用代码里埋着几万条 SQL。这些东西要从原来的库原样搬到新库上跑起来，谁都不敢拍胸脯说没问题。
风险都藏在哪？拆开看不复杂：
| 迁移阶段 | 干什么 | 风险在哪 |
|---|---|---|
| 评估 | 摸清对象和 SQL 的兼容情况 | 摸不全，漏掉的都变成上线后的雷 |
| 结构迁移 | 表、视图、约束、序列搬过去 | 类型映射、DDL 语法差异 |
| SQL 改造 | 不兼容的语句人工重写 | 量大，改漏一条就是一次生产事故 |
| 数据迁移 | 业务数据搬家 | 数据量、停机窗口 |
| 验证 | 新旧系统对账 | 人力堆出来的漫长回归 |
注意看第二行和第三行。这两块恰恰是工具最该发力、也最能分出高下的地方。市面上不少迁移方案的注意力放在数据搬运上，表结构搬过去了，数据灌进去了，SQL 层呢？留给人工。评估靠老师傅的经验，改造靠开发的肝，这就是很多替换项目工期失控的真正原因。
@TOC
二、经验估算和一张报告的区别
传统做法怎么估迁移工作量？把 DBA 和架构师拉到会议室，对着对象清单，凭经验拍。老师傅说这库大概七成能兼容，改造一个半月吧。这话没法验证，也没法追责，项目就只能信。
这种模式在库少、人熟的时候凑合能用。可替换项目往往一上来就是十几套库，还不都是你熟的库。经验这东西，覆盖面跟不上摊子。
金仓这边的思路是把这件事变成数据决策。它的迁移评估系统 KDMS 先采集，再评估，最后给你一份量化的《迁移评估报告》。报告里写的是啥？对象总数、兼容数、不兼容数、不兼容原因分类、各类对象的数据量和空间占用。改造工作量从哪来、有多少、为什么，全是一笔一笔算出来的账。
一句话概括这个差别：经验估算是拍脑袋，报告是摆账本。摆账本的好处不光是准，还在于它能拆。哪类对象的问题大、集中在哪几个 schema、需要什么技能的人来改，排期和排兵都能落到具体数字上。
三、KDMS 的三板斧：智能评估、自动转换、应用 SQL 采集
具体拆开看金仓这套工具的能力，核心是三件事。
第一件，智能评估。采集端先把源库的对象定义捞回来，注意只采结构不碰业务数据，安全上好交代。评估端跑完，对象详情页把所有不兼容信息按原因归类、按数量降序排。这个设计看着不起眼，实际用起来很救命。比如报告里看着有三条不兼容语句，点进去发现是同一个原因，解决一个问题，三条全好。吓人的总数背后，真正要动手的可能就十几处。
采集前建临时账号，Oracle 的授权是这样一串：
sql
create user KINGBASE_USER identified by "kingbasePASSW0RD";
grant connect,resource,select_catalog_role to KINGBASE_USER;
grant select any DICTIONARY to KINGBASE_USER;
grant execute on DBMS_LOGMNR to KINGBASE_USER;
grant execute on dbms_metadata to KINGBASE_USER;
grant select any transaction to KINGBASE_USER;
grant analyze any to KINGBASE_USER;账号是临时的，采完就删。
第二件，自动转换。这是金仓敢把自动转化率拿出来说的底气。实际案例里，KDMS 的对象自动转化率做到了 96% 到 98%，配套的改造工时缩减在 80% 以上。这两个数意味着什么？一套两千个对象的库，真正落到人手里需要手工改的就几十个，老师傅带着改一周和带着改一个月，是完全不同的两种项目。
自动转化率能做到这个高度，不光是转换引擎的事，也跟 KES 本身的兼容模式设计有关。金仓数据库针对 Oracle、MySQL 这些主流源库有专门的兼容模式，大量源库语法在目标端原生就能跑，转换引擎要处理的是剩下那部分硬骨头。语法兼容的地基打得深，工具这层楼才盖得高。
拿个最常见的例子说，Oracle 的分页写法：
sql
-- Oracle 经典分页，ROWNUM 套两层
SELECT * FROM (
SELECT t.*, ROWNUM rn
FROM orders t
WHERE ROWNUM <= 20
) WHERE rn > 10;这种语句在评估阶段就会给出明确的兼容结论，兼容模式下能直接跑的就标兼容，跑不了的就进不兼容清单，附上原因和改法建议。不会出现"评估说没事，上线就报错"的尴尬。
第三件，也是我认为最容易被低估的一件，应用层 SQL 采集。前面说的对象评估，覆盖的是库里的东西。但库里的对象兼容了，不代表业务跑得起来。真正要命的不兼容，往往藏在应用实际执行的那些 SQL 里，mybatis 的 mapper 文件、程序里拼接的动态 SQL、跑批脚本，这些在数据库对象清单上是看不见的。
KDMS 对这一层有专门的采集手段。静态的，扫 mapper 文件和 SQL 脚本，打包传上去就能评；动态的，采集器挂到运行中的应用上，把真实执行过的 SQL 连调用堆栈一起抓回来评。历史 SQL 采集还能从源库把跑过的语句直接捞出来。三层兜下来，应用层的不兼容在上线前就暴露了，而不是等业务上线后用户帮你发现。
这一点在做选型对比的时候值得多问一句：你家的迁移方案，评估范围覆盖到应用层 SQL 了吗？覆盖不到的话，那些改漏的语句就是替未来存的事故。
四、两种路线摆在一起看
把前面说的东西归拢一下，替换路线上两家的差异大致可以这样看：
| 对比项 | 靠经验、靠人工的路线 | 金仓 KDMS 路线 |
|---|---|---|
| 工作量评估 | 老师傅经验估算，无法验证 | 量化评估报告，逐项摆账 |
| 对象转换 | 手工改造为主 | 自动转化率 96%-98%，人工兜底 |
| 应用层 SQL | 基本靠上线后踩雷 | 静态、动态、历史 SQL 三路采集 |
| 改造过程管理 | Excel 加例会 | 系统内改、校验、留痕 |
| 工期 | 不可控因素多 | 实测工时缩减 80% 以上 |
说明一下，达梦的迁移工具也在往前走，这个对比不是说人家不行。想表达的观点其实就一个：国产库替换走到今天，数据库本体能力都够用了，真正拉开项目成败差距的，是迁移阶段有没有一套把评估、转换、验证都工程化的工具链。金仓在这件事上的投入程度，从 KDMS 把应用 SQL 采集、在线改语句带校验这些都做进产品里，是能看出来的。
五、几句给选型人的实话
如果你正在做达梦VS金仓这类选型，别光坐着听宣讲，让两家都拿你的真实系统跑一遍评估。金仓这边就是建个临时账号，KDMS 采一轮，几天后你看的是自己系统的评估报告，兼容度多少、不兼容在哪、工作量多大，白纸黑字。经验这时候就不用发挥了，数字替你说话。
评估一定要做在排期前面。先立军令状再摸家底，是替换项目最常见的翻车姿势。
应用 SQL 的评估别省。库层全绿、应用一跑就崩，这种事排查起来比评估阶段多花十倍的力气。
最后，报告拿到手别只看兼容度那个总百分比。点进对象详情看不兼容的分类，那才是你真正要花力气的地方，也是你跟实施团队谈工期、谈人手的本钱。