聊聊数据库迁移工具怎么从单机走向“云+端+服务”，KDMS架构拆解

最近这大半年，我一直在帮几个大型项目做信创数据库替换的落地工作。其实说到做替换，最让人头疼的往往不是最后的割接那一下。而是前期的摸底和评估。很多兄弟刚接手项目的时候，第一反应就是找个数据库迁移工具扫一下。但是用着用着就会发现，传统的单机版迁移工具在大型项目里，用起来特别别扭。今天咱们就结合金仓的KDMS，也就是金仓数据库迁移评估系统，来聊聊这玩意儿是怎么通过“云+端+服务”的架构，把这件别扭的事情理顺的。

一、传统单机版迁移工具到底卡在哪里

很多做技术的兄弟，手头可能都有一两个单机版的迁移小工具。以前系统小的时候，用着还行。但是现在的情况不一样了。

1.1 评估和采集往往是一锤子买卖

你拿着一个单机工具，连上源数据库。点一下开始扫描。它哗啦啦跑一遍，给你弹出一个Excel或者Word报告。接着呢？这就结束了。

这是一个很尴尬的局面。那为什么会这样呢？原因在于单机工具没有状态保存的概念。你今天扫了一遍，发现有一百个不兼容的对象。你去改了代码。明天你想再扫一遍看看还剩多少不兼容的。对不起，你只能重新连上去再跑一次全量扫描。对于企业层级里的应用来说，这种重复劳动其实非常浪费时间。而且你很难对比这两次扫描之间的差异到底是什么。

1.2 大型项目里的信息孤岛问题

再说说大型信创项目的情况。这种项目往往不是一个人在战斗。有做Oracle采集的，有做MySQL采集的，还有负责改应用代码的。

如果大家都用各自电脑上的单机工具。张三扫出来的报告，和李四扫出来的报告，格式可能都不一样。大家汇总的时候，全靠人工去对Excel表。这就会形成一个信息孤岛。你不知道别人那边改到什么进度了。你也不知道你改的这个存储过程，是不是跟别人改的表结构有冲突。这种缺乏协同的情况，往往仅仅只是让项目进度停滞，根本推不动。

1.3 遇到报错只能自己查文档的尴尬

还有一点很搞人心态。单机工具往往是个黑盒。你扫着扫着报错了，比如报一个 insufficient privileges 的错。你只能去百度，去翻官方文档。有时候文档写得又很晦涩。你卡在这个地方半天，找不到人问。这对于项目实施团队来说，是一个隐性的成本黑洞。

二、KDMS“云+端+服务”到底是怎么个玩法

为了解决上面说的这些麻烦，金仓在KDMS这款产品上，其实换了一个思路。他们没有死磕单机软件，而是搞了一个“云+端+服务”的架构。咱们拆开来看看。

2.1 先看整体架构长啥样

我画了个简单的图，大家先有个直观的印象。其实就是把原来塞在一个客户端里的东西，拆成了三个部分。

你看这个结构。它不是孤立的。

2.2 “端”的作用：下到现场去摸底

“端”指的是数据采集软件。这个东西是装在现场的机器上的，或者能连上现场网络的那台机器上的。

它的任务很纯粹。就是去连Oracle、MySQL、SQLServer或者DB2。把里面的表结构、视图、存储过程、触发器这些信息捞出来。它甚至还能去应用里捞SQL。捞完之后，它不打报告。它把这些信息打成一个压缩包。这个压缩包里会有一个很重要的文件，叫 COLLECTOR_META.dat。这个文件记录了这次采集的元信息。

端的好处在于，它只需要跑一次。跑完了，现场的网络隔离问题也就解决了。你拿着这个包走就行。

2.3 “云”的作用：把散落的信息收拢

采集包拿到了，往哪传呢？这就到了“云”的部分。KDMS的评估系统其实是一个Web应用。你可以把它部署在项目组的内部服务器上，或者直接用金仓提供的在线服务。

你把采集包传上去。系统会自动解析，建立评估项目。这时候，信息孤岛就被打破了。不管你是从哪个库采的，不管是谁去采的，所有的对象、所有的兼容性报错，全都在这个统一的Web界面里了。

2.4 “服务”的作用：背后有人帮你兜底

这是我觉得最实用的一点。遇到那种怎么改都改不对的SQL，或者连源库都连不上的奇葩报错，你不用自己硬扛了。评估系统里集成了在线支持的能力。你可以直接把问题抛给背后的DBA团队。这就相当于你买工具的同时，还买了一份保险。

三、具体怎么干活：从采集到评估的闭环

咱们别光说概念，看看这东西实际点起来是长什么样的。

3.1 采集前得先把账号搞定

在用“端”去采集之前，你必须在源库里建一个专门用的账号。而且这个账号只要读结构的权限，不要给写业务的权限。这是安全底线。

拿Oracle来说，如果是普通的非CDB模式，你通常得这么建。

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;
grant EXP_FULL_DATABASE to KINGBASE_USER;

这里面每一条都有用。比如 select any DICTIONARY，这是去读数据字典的。没有这个，它连表名单都拿不全。再比如 DBMS_METADATA，这是用来抽取DDL语句的。你如果不给这个权限，采集器就拿不到建表语句的详细文本。如果是12c的CDB模式，那就更麻烦一点，你得建COMMON USER，而且后面要加上 container=all。

再看MySQL。MySQL就简单粗暴一点。

CREATE USER 'MySQL 用户名'@'host' IDENTIFIED BY 'MySQL 密码';
flush privileges;
GRANT ALL ON *.* TO 'MySQL 用户名'@'host';
flush privileges;

但是这里有个大坑。如果是MySQL 8，因为密码加密方式变了，你往往仅仅只是执行上面的语句，连上去还是会报错。你得额外执行一句把密码插件改回去。

ALTER USER 'MySQL 用户名'@'host' IDENTIFIED WITH mysql_native_password BY 'MySQL 密码';

如果不加这句，采集器启动后大概率会弹出一个 CLIENT_PLUGIN_AUTH is required 的报错。这种细节，如果你没有踩过坑，光看报错信息是一头雾水的。

SQLServer的建账号也很有意思。它分login和user两步。

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'

你得先建一个登录实例的账号。然后再到具体的数据库里建一个用户映射过去。最后给一个 db_owner 的角色。如果不给这个角色，有些特殊的系统表你是读不到的。

3.2 数据库对象采集的细节

账号建好了，打开采集端的界面。新建一个采集任务。

你需要选数据库类型。比如选了Oracle。接着填IP、端口、SID或者服务名。这里有个细节，如果是RAC环境，你别选SID，你得选服务名。模式那里要注意大小写，Oracle对大小写是敏感的，你写错了就采不到东西。

然后你可以勾选要采什么。表、视图、序列、函数、存储过程、触发器。全选上也行。如果你想知道大概有多少数据，也可以勾选采集数据量大小。它不会去读真实业务数据，它只是去查一下系统表里的统计信息，看看每张表大概有多少行，占多大空间。

点立即创建。它就开始跑了。跑完了状态会变成“采集完成”。这时候你点“下载采集包”。一个zip文件就下来了。记住，这个zip包里的 COLLECTOR_META.dat 文件很重要。各个采集包是不能混用的，不能把这个包里的dat文件拷到那个包里去。如果混用了，在“云”端创建评估项目的时候，系统直接就给你拒绝了，说meta文件不合法。

3.3 连历史SQL和应用里的SQL也不放过

KDMS这点做得挺细的。除了采数据库结构，它还能采SQL。

一种是采历史SQL。比如Oracle，它是去查 v$sqlarea 这个视图。这里面存着共享池里执行过的SQL。MySQL呢，它需要你先把日志打开。

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

把它输出到表里，然后再去查 mysql.general_log。这种做法能捞到数据库层面真实跑过的SQL。

另一种是应用采集。这就更贴近业务了。它分静态和动态。静态就是你去把Mybatis的xml文件打成zip包传上去，它帮你把里面的SQL抠出来。或者把.sql脚本打包传上去。

动态采集比较猛。它是通过Java探针的技术，挂载到你的业务应用上。应用跑起来，它就在旁边盯着。你点了哪些页面，触发了哪些SQL，它全给你记下来。但是注意了，手册里写得很清楚，这个东西会导致业务性能下降。所以绝对禁止直接在生产环境上挂这个探针。你得在测试环境模拟业务操作来采。

四、评估系统是怎么打破孤岛的

采集包拿到了，现在咱们登到“云”端的评估系统去看看。默认地址是 http://IP地址:19007/。初始账号密码一般是 admin/Kingbase@2024。

4.1 上传采集包后的自动分析

在评估管理页面新建评估。把刚才的zip包传上去。

系统会自动识别出这是从哪个库采来的。如果是Oracle采的，兼容模式会默认选Oracle。目标KES版本默认选KES_V9。你可以改这些选项，然后点确认。

接着它就开始在后台跑了。跑完之后，你点进去看评估概要。它会告诉你，总共有多少个对象，多少个兼容，多少个不兼容。如果你之前勾选了采集数据量，这里还会显示总共有多少条数据，占多少GB的空间。这对评估硬件资源是很有用的参考。

4.2 不兼容语句的在线修改与校验

这是打破信息孤岛的核心功能。

你点进对象详情。它不会把一千个不兼容的对象平铺给你看。它会做一个分类汇总。比如它告诉你，有50个对象是因为“不支持该数据类型”不兼容的。你点开这个分类，就能看到具体是哪50个。

这时候你点一个对象。右侧会弹出一个面板，显示原始的SQL语句。下面还有个控制台告诉你为什么不兼容。

你可以点“编辑”按钮。直接在这个Web界面上改SQL。改完了，你点“执行校验”。系统会在后台模拟KES的语法去跑一下你改过的语句。如果下面控制台提示校验通过了，你点“保存”。

保存之后，这个对象的评估结果就变成“兼容”了，评估方式会打上“手动修改”的标签。而且最关键的是，总体的兼容度百分比会实时重新计算。你不需要再导出表格去用计算器算了。

4.3 评估报告的导出与分工协作

因为这是在Web端，项目组里的所有人都可以登录来看。

比如老王负责改存储过程，他就在筛选里只选“存储过程”和“不兼容”。他改完一个存一个。小李负责改表结构，他就看表相关的。大家同时在一个系统里干活，互相能看到进度。这就是团队作战的感觉。

改得差不多了，项目经理点一下“下载评估报告”。它会生成一个Word文档。如果有不兼容的对象没改完，它还会额外生成一个Excel，把剩下的问题全列出来。拿着这两个文件去开会，去汇报，心里就有底了。

在评估详情页面，还有个“下载对象语句”的按钮。点一下，它会把所有对象生成.sql文件。这些文件是已经经过自动转换，加上你手动修改后的最终版本。你可以直接拿这些脚本去KES上跑了。

五、实战中经常碰到的几个坑

最后聊聊在实际用这个采集端的时候，大家经常遇到的几个报错。手册里也写了，我用大白话给大家翻译翻译。

5.1 测试连接失败的各种情况

这是最常遇到的。你刚填完IP端口，点测试连接，弹出来一个 Initialization of the database failed!。

别慌。这不是程序崩了。这就是连不上。

那么怎么排查呢？首先，你在这台装采集端的机器上，去ping一下那个IP。看看网络通不通。接着，看看端口有没有被防火墙挡住。然后，检查你刚才建的账号密码对不对。你可以用Navicat或者DBeaver这类客户端工具，用这个账号去连一下源库。如果客户端都连不上，那采集端肯定也连不上。如果客户端能连，采集端连不上，那就去看日志。日志在安装目录下的 /logs 文件夹里。

5.2 特定数据库的奇葩报错

比如Oracle采集的时候，报一个 insufficient privileges。你明明把权限都给了呀。这时候你去检查 $ORACLE_HOME/network/admin 目录下的 sqlnet.ora 文件。看看里面是不是有一行 SQLNET.AUTHENTICATION_SERVICES=(NTS)。如果有，而且没有被注释掉，往往就是它在捣鬼。你在这行前面加个 # 注释掉，重启一下监听，通常就能好。

比如MySQL采集，报一个 Latinlisnotsupported。这是因为你源库的字符集用的是拉丁字符集。KDMS不支持这个。你得先把源库的字符集转成UTF-8，然后再去采。

再比如SQLServer采集，用新账号连不上，报 18456 错误。这是因为SQLServer默认只允许Windows身份验证。你得用Windows账号登进去，在数据库属性的安全性选项里，改成“SQLServer 和 Windows 身份验证模式”。改完得重启服务才行。

还有个SQLServer的报错很搞人。叫 SetARITHABORT 不正确。报错信息一大串，什么计算列、索引视图之类的。

其实解决起来就一句SQL：

ALTER DATABASE yourdb SET ARITHABORT ON

这是干嘛用的呢？其实就是SQLServer在处理某些特定对象（比如有计算列的索引）的时候，要求一个特定的SET选项必须打开。采集器去读这些对象的结构，如果不打开这个选项，它就会报错。你打开就行了。但是要注意，采完之后，如果你觉得这个设置影响了别的东西，记得改回去。

如果是还原SQLServer数据库备份数据的时候报“备份集中的数据库备份与现有的数据库不同”。这个不是采集端的问题，这是你操作系统的失误。你得先在SSMS里手动建一个同名的目标数据库。然后右键点击还原。在选项页签里，一定要勾选“覆盖现有数据库”。不勾选它就会报这个错。

六、总结几句掏心窝子的话

其实做数据库迁移，工具只是个辅助。真正麻烦的是流程管理和团队协同。

传统的单机版数据库迁移工具，把人当成了一个个孤立的信息节点。每个人自己扫，自己改，自己出报告。这在小型项目里能跑通。但是放到大型信创项目里，那种几十个子系统、几百个数据库节点同时推进的情况下，单机工具只会让项目乱成一锅粥。

KDMS这套“云+端+服务”的思路，其实是把工具变成了一套管理系统。端负责把现场的脏活累活干完，并且标准化输出。云负责把所有的信息汇总，提供在线修改和协同工作的平台。服务负责在大家卡壳的时候拉一把。

这种架构上的变化，带来的不是扫描速度快了百分之几。而是让整个项目的实施过程变得可控了。你随时能知道项目的整体兼容度到了多少。你随时能知道还有哪些高风险对象没有处理。你不用再拿着几个Excel表去开会扯皮了。

对于很多正在做或者准备做信创替换的兄弟们来说，选工具的时候，别光看它能兼容多少种语法。你更得看看，它能不能支撑得起你们团队协同作战的需求。这才是关键。