数据迁移工具 KDMS 帮我把一本糊涂账算清了

搞迁移的都被同一个问题追问过："这套系统迁过去，到底要动多少东西？"

我经手过一个 SQL Server 老系统迁国产库的项目，立项会上领导连珠炮一样问：兼容度多少？改造量多大？三个月能不能完？搁在以前，这些问题靠的是老 DBA 的经验估算------"应该问题不大""估计俩月"。这种回答，说的人心虚，听的人没底。后来项目里上了数据迁移工具 KDMS（金仓数据库迁移评估系统），同样的问题，我们改成拿一份《迁移评估报告》回答。这篇就照着《KDMS 用户手册》，说说这份报告是怎么出来的、里面到底有什么。

评估为什么难

没工具那阵子，我们的评估是这么做的。我登到库里数对象，数了两天，表多少张、视图多少个、存储过程多少个，列了张 Excel。老张抽了几十个存储过程逐条读，凭经验给兼容度打了个分。工作量按人天拍，拍完没人敢签字。最怕的是风险后置，不兼容的点要等改造甚至上线才冒出来，返工成本全堆在后面。这种评估，说的人心虚，听的人也没底。

KDMS 的思路是把这件事自动化：机器先采集，再分析，最后出量化报告。评估从"人估算"变成"数据说话"。

报告是怎么生成的

先说数据库采集客户端，摸家底用的。连上源库之后，它把对象的结构信息收拢到一起，表、视图、触发器、约束、序列、函数、存储过程都在范围内。有一点得专门提：它只碰结构，不读业务数据。

权限上，手册建议单建一个采集临时用户，采完就删，我们照做的。以我们项目的 SQL Server 源库为例，手册第四章给的建用户脚本拢共三条：

sql 复制代码

create login kingbase_user with password='Kingbase123',
    default_database = 待采集数据库;

create user kingbase_user for login kingbase_user
    with default_schema = dbo;

exec sp_addrolemember 'db_owner', 'kingbase_user';

评估一跑完我就把这账号删了，源库里不留痕迹。源库覆盖面是 Oracle、DB2、MySQL、SQLServer、SyBase 这五家，其余几家的建用户脚本手册第四章也都给了现成的。

应用采集客户端管的是应用侧。它抓应用运行时真实执行的 SQL 和对应堆栈信息，也支持静态代码扫描。动态采集这条路我多说一句：Oracle 侧是从 v$sqlarea 里捞，带执行次数和最近活跃时间；MySQL 侧走 general_log，启用就两条语句，手册原文照抄：

sql 复制代码

SET GLOBAL general_log = ON;
SET GLOBAL LOG_OUTPUT = 'TABLE';

-- 看抓到了什么，一句查询的事
select * from mysql.general_log order by event_time desc;

我们项目源码不全，真实负载就是靠这条路摸出来的。另外手头攒的那些离线材料，Mapper 的 xml、历年的 sql 文件、Java 程序运行的 jar，手册里也都留了入口，一样能喂进去评估。

采集完产出的是一个 zip 数据包（200MB 以内）。到评估管理页面新建评估，把包传上去，源库类型和兼容模式会自动识别填充，选好目标 KES 版本，点确定，剩下的就是等。状态变"完成"，报告就有了。

报告细到什么程度

这部分是重点，我一层一层说。

评估列表先给总数：每个评估项目一行，源库类型、目标 KES 版本、评估时间、有效对象数、兼容数、不兼容数、兼容度百分比，一眼看清整体盘面。

点进详情是评估概要。如果采集时含了数据迁移工作量，这里还会额外展示数据量和数据大小------数据量是所有表加起来多少条，数据大小是占多少空间，这两项是评估数据搬迁工作量的直接输入。

再往下是我认为最有价值的一张表：主要对象统计。它按对象类型分行，每行给出对象数量、兼容数、不兼容数、手动调整数、兼容度。手册示例库的统计结果摆出来是这样的：

对象类型	数量	兼容	不兼容	兼容度
TABLE	1054	1053	1	99.91%
TRIGGER	8	8	0	100%
SEQUENCE	15	15	0	100%
PROCEDURE	1	1	0	100%
VIEW	1	1	0	100%
FUNCTION	1	1	0	100%
INDEX	1	1	0	100%

一千多张表，不兼容的就 1 张。短板是哪类对象、改造量压在谁头上，扫一眼就有答案，不用猜。

应用采集的评估是另一个视角，按 SQL 语句类型统计。手册示例里能看到 SELECT 49 条兼容 46 条、3 条不兼容，COMMENT 326 条全兼容，FUNCTION_CREATE 24 条里有 3 条不兼容、兼容度 87.50%。哪类语句要改、改几条，全是明数。

还有一层更细的，对象详情页。它把所有不兼容信息按原因归类，按数量降序排列。这个设计特别对我的胃口：手册里专门提到，有三条语句是同一个报错导致的不兼容，点开一看归在一起，实际只需解决这一个问题。不兼容的"数量"和"问题数"是两回事，聚合之后，真实改造量往往比表面数字小。

碰上不兼容的对象也不用导出再改。详情面板里原始语句和报错信息并排，点编辑进 SQL 修改界面，左边原文右边改，改完执行校验，通过后保存。保存完这条语句的评估结果就变成兼容，评估方式标为手动修改，总体兼容度跟着重新计算。改一条，盘面变一次。

最后是交付物。评估详情页能下载评估报告，主体是一份 word 文档；存在不兼容对象时，会额外生成一个 excel，把所有不兼容对象逐条记录在册。对象语句也能整体下载，按类型分成 table、view、procedure、function、trigger、sequence、index 七个 .sql 文件，自动转换加手动修改的结果都在里面，直接拿去建目标库。

从经验估算到数据决策

手册里有两句话我划了线。一句是，用户可下载评估报告，进行迁移工作量的评估和制定迁移计划；另一句是，为数据库迁移的兼容性评估分析提供数据支持，帮助用户做出科学合理的迁移选择。

这两句看着平淡，实际就是"经验估算"和"数据决策"的分界线。回到开头立项会的三个问题。兼容度多少？报告里有百分比，还按对象类型拆了明细。改造量多大？不兼容对象按原因聚合，excel 清单一拉，改多少条、改哪几条，排期有了依据。三个月完不完得成？对象底数、数据量、数据大小都在概要页上，工作量估算从拍脑袋变成做算术。

后来我们开计划会，桌上没放 PPT，就摆着那份 word 加 excel，有异议的当场对清单。那次会开得比哪次都快。

收尾

回看这两个月，KDMS 在我这儿的定位挺简单，它不替你迁，它帮你把账算清楚。兼容度是跑出来的，改造清单是一行一行摆着的，数据量就印在概要页上。立项会上的问题，多数在报告里就有答案。

如果你手边正好有个想迁又不敢拍板的系统，建议先别谈方案，拿个采集包跑一次评估。报告出来，很多争论自然就停了。