数据库替换项目的时间,很少花在大家以为的地方。
选型评审两周,压测两周,数据搬迁通常一个周末就够了。真正吃掉几个月的是中间那一段------把几千个存储过程、几万条应用 SQL 逐个看过去,判断哪些能直接跑、哪些要改、改了之后测试怎么覆盖。
这一段没有掌声,风险却最高。改漏一条,上线当晚就是故障。
所以比较两家的迁移能力,比性能跑分更有意义。下面把达梦和金仓的迁移工具放在一起看,先摆事实,再谈差异。
一、先把两边的工具链摆清楚
达梦这边是 DM DTS(DM 数据迁移工具)。 按达梦官方文档,DTS 提供主流大型数据库迁移到 DM、DM 到 DM、文件与 DM 互转等功能,功能模块分为迁移、对比、评估、转换几块,采用向导方式引导用户逐步完成。它支持视图、存储过程/函数、包、类、同义词、触发器等对象的迁移,支持数据类型自动映射与编码转换,支持全量与增量结合,也支持 Web 端操作和监控。工具本身随数据库安装包一起分发,在 dmdbms/tool 目录下启动。
金仓这边是三件套。 KDMS(金仓数据库迁移评估系统)负责迁前评估与对象转换,KDTS 负责全量数据迁移,KFS 负责增量实时同步与双轨并行。三者分工明确:KDMS 只做迁移准备,不介入生产读写,不承载业务事务。
先说清楚一件事:达梦 DTS 不是一个弱工具。达梦公开的电力行业案例里,D5000 智能电网调度系统的迁移涉及一万多张表、三千多张视图、超过五十万行存储过程,由 DTS 完成。能扛住这个体量,基本功是扎实的。
所以差异不在"有没有",而在"边界画在哪里"。
二、评估这一步,决定了后面所有的预算
替换项目立项时,项目经理最需要的一个数字是:这活儿要多少人天。
传统做法是找几个资深 DBA,抽样看一部分对象,凭经验往上估。估高了预算过不了,估低了后面全是加班。而大型系统动辄上万个数据库对象,抽样的代表性本身就存疑------专业 DBA 也很难在未经严格验证的情况下判断风险、难度和工作量。
两家的评估报告都在解决这个问题,但产出的颗粒度不同。
达梦 DTS 的评估功能会生成评估报告,按其官方文档,内容包括数据库信息、对象兼容信息、表统计信息;对判定为"不兼容"的对象,可以点开查看具体不兼容原因,再把修改后的语句补充到"转换后 SQL"模块中。这是一条完整的可用路径,信息也是准确的。
KDMS 的《迁移评估报告》多了一层。除了兼容性总览(按表、视图、存储过程、函数、触发器等类别分别统计自动转换成功率),还包括风险项明细清单------逐条列出需人工介入的对象、原始代码位置、兼容问题描述、推荐解决方案与关联影响范围;以及工作量预测模型,综合对象复杂度、跨模块依赖关系和历史项目经验参数,输出改造人天预估、回归测试周期建议和关键路径提示。
最后这一项是分水岭。"不兼容对象有 137 个"是一条技术信息;"预计改造 46 人天,回归测试 3 周,关键路径在结算模块"是一条可以直接进项目计划、进预算表、进甲方汇报材料的信息。
评估报告从技术文档变成立项评审、预算编制、资源协调的交付物,迁移决策才算真正从经验驱动转到数据驱动。
三、真正的分水岭:评估的边界画在哪一层
这是本文最想说清楚的一点。
绝大多数迁移评估工具,扫描对象是源数据库。连上库,读系统表,把里面的表、视图、存储过程、函数、触发器拉出来分析。这条路径覆盖了库内的一切。
问题是,库内不等于全部。
一个跑了十年的业务系统,大量 SQL 并不存在于数据库里。它们在 Java 代码的字符串常量里,在 MyBatis 的 XML 映射文件里,在 C# 的拼接语句里,在运行时才根据条件拼装出来的动态 SQL 里。这些语句从来没有以对象的形式在源库中登记过,任何只连数据库的扫描器都看不见它们。
而它们恰恰是上线后最容易出事的部分。库内对象在割接前就能全量验证一遍,应用层 SQL 却要等到具体那条业务分支被触发才会暴露。一个季度才跑一次的报表、一年一次的年结、只有特定角色才能进的审批页面------这些路径上的不兼容语句,常常是上线三个月后才被发现的。
KDMS 明确把这块划进了评估范围:支持无侵入方式采集业务应用的 SQL,并对其做迁移评估与转换,不要求改造业务代码。采集端分为两类模块,数据库元数据采集只以只读权限连接源库、提取 DDL 定义与约束权限等静态结构信息,不访问任何业务数据;应用 SQL 采集则走探针路径,低侵入、高实时性。V4 版本把这块的重点放在异构采集从"能采"升级到"智采"。
达梦官方文档中,DTS 的评估与转换描述围绕的是源库中的数据库对象。在公开资料里,没有查到对应的应用层 SQL 采集能力描述。
这个差异的实际含义是:两个工具都告诉你"库里有多少要改",只有一个会告诉你"代码里还有多少要改"。而在一个真实的替换项目里,后者的数量往往比前者更大,也更难估。
四、"自动转换率"这个数字,该怎么读
宣传材料里经常出现"自动转换率 96%""97%"这类数字。这个指标有用,但读的时候要先问三个问题,否则容易被自己的数字误导。
第一,分母是什么? 是对象个数还是代码行数?一万张结构简单的表和五百个嵌套三层的包体,按对象数统计出来的成功率会非常好看,但工作量根本不在表上。按代码行数统计通常更接近真实工作量。
第二,"自动转换成功"的判定标准是什么? 是语法转换后能在目标库编译通过,还是执行结果与源库一致?能编译不代表逻辑等价------隐式类型转换、排序规则差异、空值处理、日期函数边界,这些都能让一段"转换成功"的代码跑出不同的结果。
第三,统计范围含不含应用层? 如果只统计库内对象,那么按上一节的逻辑,这个分母本身就是不完整的。
有几组来自公开渠道的数据可以先做参照:某案例中对 2300 余个存储过程、函数及视图做语法扫描,识别出约 17% 的不兼容语法(如 ROWNUM 使用、包体嵌套过深),系统自动生成修改建议并完成自动化重构;另一案例中需人工适配的存储过程占总量约 0.8%,预估工期缩短约四成。这两组数字的口径不同,不能直接相加或平均,但它们说明同一件事------不同系统的自动转换率差异极大,取决于源库里那些代码写得有多"野"。
所以对采购方更实用的做法不是记住某个百分比,而是:拿自己最复杂的那个模块,让两家各跑一次评估,对比报告里的风险项清单和人天预估,再对着代码抽查几条,看谁的判断更准。评估工具的价值在于预测准确,不在于数字好看。
五、达梦的强项也要说
写对比文章最容易犯的错是只讲对手的短板。这里补两句公允的。
达梦 DTS 的向导式设计上手快,随数据库安装包分发,不需要额外部署,对中小规模、单库迁移的场景效率很高。前面提到的 D5000 案例证明它在超大规模项目里也经过了实战检验。
一个来自达梦官方文档的技术细节值得注意:DTS 的语法规则模板------用于对视图、存储过程/函数、触发器做 SQL 语法转换的功能------文档中标注仅支持 SQL Server→DM 和 MySQL→DM。如果你的源库是 Oracle,这条路径上的对象转换策略与前两者不同,选型时建议直接向达梦确认 Oracle 源的具体转换覆盖范围,以官方最新文档和 POC 结果为准。
金仓这边也有边界要说清楚:KDMS 只做迁移准备,不做数据搬运,数据部分要靠 KDTS 和 KFS;评估报告的定位是"辅助决策支持",不能替代测试环境的实际验证;自动转换覆盖的是有规则可循的部分,业务逻辑深度绑定数据库特性的对象,该改写还是要改写------KDMS 内置 7×24 在线工单和 DBA 团队响应,存在本身就说明厂商认这一点。
六、选型时值得问的六个问题
把上面的讨论落成可执行的清单:
- 评估范围是否包含应用层 SQL?动态拼接的 SQL 能不能采到?采集是否需要改造业务代码?
- 评估报告里有没有人天预估?依据什么模型?能不能直接进项目预算?
- 自动转换率的统计口径是对象数还是代码行数?判定标准是编译通过还是结果等价?
- 源库是 Oracle 时,存储过程和包体的转换覆盖率具体是多少?能否提供同类项目的复盘数据?
- 评估出的风险项,有没有配套的支持通道?响应时限是多少?
- 采集的信息是否需要出内网?涉密项目能否私有化部署?
这六个问题的答案,比任何一份对比表都更能决定项目周期。
七、回到时间账上
替换项目里,选型决定的是能不能用,迁移工具决定的是多久能用上。
前者有大量公开测试可以参考,后者往往到实施阶段才见分晓。而实施阶段的成本又是最难追加预算的------立项时报的是三个月,做到第五个月还在改存储过程,这种局面对甲乙双方都不好受。
评估工具真正的价值,是把这个数字在立项之前就算准。库内对象要算,代码里那些从来没进过数据库的 SQL 也要算。
后面那一部分算不算得到,是目前两家工具最实际的一处分野。