文章目录一、单机版迁移工具为什么容易遇到协同瓶颈二、KDMS 的“云端服务”分别解决什么问题1. 云把评估从一份报告变成项目底账2. 端在现场完成数据采集而不是搬走生产数据3. 服务把 DBA 经验变成在线可复用的支持三、三者怎样形成一条闭环链路四、一次实际可执行的 KDMS 项目准备清单五、协同架构的边界与客观看法六、我对数据库迁移工具的四个判断七、把协同结果留成可复查数据我头一回把数据库迁移工具用在这种大型替换项目里的时候我第一个感觉到的不是它转换得有多快。而是什么呢是“信息怎么老在丢”。评估的人呢在一张表里记对象数量。采集的人呢把脚本全扔在自己电脑上。开发的人就在群聊里面发那些转换失败的 SQL。DBA 呢只能等到了晚上再一块儿来回答问题。你看每个人都在干活但是项目里面就是没有形成一条能追得下去的链路。这是一个问题。那为什么会这样呢原因就在于大家各干各的没串起来。也就是因为这样我才算重新去理解了 KDMS 到底在干吗。以前那种老式的单机版工具你拿来搞点小规模、边界很清楚的任务那是没问题的。但是在信创项目里面情况就不一样了。什么叫信创项目的情况呢就是源库有很多个要分很多批次而且是一大帮人一起参与。这时候迁移工具它就不能光管导入导出了。它还得负责把评估啊、采集啊、转换啊还有后面的支持给组织起来。KDMS 搞的这个“云端服务”架构其实就是把这三个角色给拆开然后又用一条线连起来。云端嘛就管迁移评估和项目上的管理。端侧呢就跑到客户现场去采数据。服务那边就是让 DBA 在线给你提供支持。它这个架构的价值在哪呢不在于说它把所有活儿都塞进了一个界面里。而在于它让你走的每一步都有记录留下来都有具体的人负责而且后面还有跟进的动作。一、单机版迁移工具为什么容易遇到协同瓶颈单机工具它不是说不能用。它的问题在于什么呢在于它的边界跟大型项目的组织方式对不上号。工具装在某个人的电脑上那配置文件啊、扫描出来的结果啊、转换的日志啊也就全跟着这台电脑走了。项目刚开始的时候可能也就一个工程师在搞。遇到问题他直接把日志打开看一眼就处理了。但是呢当项目变大了变成好几个源库、好几个目标库还有好几个实施小组一起干的时候。事情就不是那么回事了。第一个问题就是评估的口径对不上。不同的人用的脚本版本可能都不一样。扫同一个东西可能给出来的分类就不一样。有的人呢他就只统计表啊、索引啊、存储过程。有的人呢他还会把应用代码、定时任务还有报表的 SQL 都给算进去。最后你一看算出来的工作量那根本不是项目真正的工作量。那是什么呢那就是每个人自己经验凑在一起的一个数字罢了。第二个问题就是采上来的结果没法及时地传回去。生产环境啊通常来说是不允许你把完整的数据直接拉到个人电脑上去分析的。端上采完之后你得脱敏啊压缩啊还得按权限传上去。如果这时候你还是靠人工去拷文件。那版本冲突啊东西漏了啊这种事几乎就没法避免。某个源库昨天明明刚采过今天它里面加了新对象了。但是你的项目表里面显示的还是昨天那个老结果。这种“看着像是干完了”的状态其实是最危险的。第三个问题就是出了问题没有闭环。转换要是失败了开发得知道源对象是什么、目标对象是什么、哪句 SQL 报错了还有建议怎么处理。DBA 呢得看到怎么复现这个问题影响范围有多大。项目经理得知道这玩意儿会不会把切换给卡住。但是单机工具呢它往往仅仅只能留下一份错误日志。它没法把分派问题啊、回复问题啊、验证问题啊给串成一条线。我会把迁移项目里面要协同的东西给整理成下面这四类这张表看着挺普通的吧。但是呢它把一句“我已经查过了”变成了一种“别人能拿过去重新查”的东西。大型项目里面真正缺的往往就是这种能把活儿交出去的能力。二、KDMS 的“云端服务”分别解决什么问题1. 云把评估从一份报告变成项目底账在 KDMS 这个架构里面云端主要干的事儿就是迁移评估。它不会直接去连客户现场的数据库。它是干嘛的呢它是等着接收端上采上来的那些结构化结果。然后对这些对象去分类啊做兼容性分析啊估算一下工作量。最后生成一份迁移评估的报告出来。对于这个报告呢我个人其实更看重里面的“问题明细”。而不是最后那个所谓的自动化率有多高。一个真正有用的评估结果它起码得能回答出这几个问题来。有多少表啊多少视图啊多少索引、函数和存储过程。哪些东西是可以直接转过去的。哪些语法必须得人工去看一眼。哪些问题其实是应用层那边惹出来的。每一类问题打算让谁去处理放在哪一个批次去处理。这样的话这个评估报告它就不再只是投标那时候用来凑数的一个估算材料了。它就变成了你真正去实施的时候手里的一本任务底账。云端呢还特别适合拿来搞版本管理。源库你重新采了一次之后系统就能把这两次的结果拿来做对比。它能分得清哪些是“新加的对象”哪些是“已经修好的问题”还有哪些是“一直拖着没解决的问题”。这样一来呢项目经理就不用对着好几个 Excel 文件去瞎猜进度了。开发的人也能清楚地知道自己现在手里改的到底是哪一版的对象。2. 端在现场完成数据采集而不是搬走生产数据端侧呢其实就是部署在客户环境里的一个采集软件。它要干的活儿就是去连源数据库。然后把对象定义啊、依赖关系啊、配置啊、还有应用的 SQL 这些评估需要的东西给弄下来。接着呢再按照项目定好的规则把结果传上去。如果是对着生产环境的话我一般会把端侧的权限设成只读。给连上去的那个账号设好它能访问的范围设好超时时间还有并发数不能超过多少。而且采数据的这个过程我会让它全记在审计日志里面。还有一点要搞清楚端侧采集它并不等于把业务数据全量给复制一份过来。迁移评估刚开始看的是什么看的是元数据还有平时是怎么访问的。只有到了那种明确授权了的验证环节你才需要去抽一点样本数据出来。你把“采评估信息”和“搬业务数据”这两件事给分开。这么做的好处是生产环境的压力会小很多。而且敏感数据离开客户现场的风险也能降低不少。下面这段 SQL 呢是我平时用来核对采集结果的一个示意。它其实仅仅是表达一个检查的思路。真正到项目里字段叫什么、视图叫什么你还是得去看你用的那个版本的手册。SELECTobject_type,COUNT(*)ASobject_count,SUM(CASEWHENcompatibility_statusNEED_REVIEWTHEN1ELSE0END)ASreview_countFROMmigration_inventoryWHEREproject_id:project_idGROUPBYobject_typeORDERBYobject_type;我会把跑出来的查询结果跟端侧日志里记的扫描数量放在一起交叉对一下。接着呢再随便抽几个对象出来看看它的定义全不全。数量对上了并不代表里面内容就是全的。所以抽样这一步你是省不掉的。3. 服务把 DBA 经验变成在线可复用的支持服务这边呢就是让 DBA 或者是迁移专家在线上参与进来。它要解决的一个问题就是“工具把问题找出来了那接下来谁来拍板呢”转换引擎它能告诉你某个语法它不兼容。但是它没法替业务团队去决定这东西到底应该改写成什么语义。采集端它能报出来一个依赖关系。但是它也没法替项目去决定到底是先迁哪一批。在线服务最关键的一点就是把回答给绑在问题单上。而不是说在聊天软件里扯几句就算完了。每一条给出去的建议都得关联上源对象是什么、目标对象是什么、是哪个版本的、验证结果怎么样。在这个问题关掉之前实施的人得重新去跑一下转换或者测一下 SQL。服务的人得去确认这个结果对不对。然后平台再把关闭的时间给记下来。这么一点点攒下来的处理记录等下一次碰到差不多的对象你直接拿过来用就行了。三、三者怎样形成一条闭环链路否是云端创建项目与评估规则端侧连接源库采集云端生成对象与SQL清单团队分派转换和改造任务端侧执行样本迁移与校验服务侧DBA在线复核验证通过?形成批次报告并进入切换我一般会把这个项目给拆成六个批次。也就是“评估、样本、全量、增量、切换、观察”。评估这个批次呢就只管确认对象和风险。样本批次去验映射规则对不对。全量批次去处理那些历史数据。增量批次去验持续同步有没有问题。切换批次去控停机的时间窗口。观察批次就把回退的条件给记下来。每一个批次都得在云端把输入的东西、输出的东西还有最后的结论给留住。这样就不会出现后面阶段把前面阶段的东西给盖掉的情况了。如果是好几个人一起干呢还得把权限和职责给写明白。项目管理员他负责建任务和建批次。采集的人他只能去管端侧的连接。开发的人就去处理应用的 SQL 和转换的脚本。DBA 呢就负责审核给出去的建议。验收的人就看报告和校验的结果。把权限分这层并不是说非要给流程添堵。而是为了防止出现谁都能去改关键结论的这种情况。四、一次实际可执行的 KDMS 项目准备清单在真正去采数据之前呢我会先去搞五项准备工作。第一个呢就是得把源库和应用的清单给建起来。除了数据库实例你还得把应用叫什么、怎么连的、批处理作业有哪些、报表平台是哪个、谁负责的全给登记上。因为很多兼容性的问题最后其实是出在应用连接和定时任务上的。而不是出在表结构上面。第二个定好采集的时间窗口和账号权限。采数据这个活儿你得躲开业务最忙的那个峰值。连上去的那个账号一定要用最小权限。而且网络啊、驱动啊、防火墙策略啊这些你得提前去验一验。如果端侧连都连不上那你云端报告做得再漂亮那也是白搭没有意义。第三个把评估的标签给定义好。比如说你把对象打上“自动转换”、“规则转换”、“人工重构”、“暂不迁移”这样的标签。而且你还得规定好每个标签你得拿什么东西来当验收的证据。标签定得越清楚后面分活儿的时候就越顺畅。第四个把有代表性的样本给备好。选样本的时候你不能光挑那种最简单的表。你得把大表啊、复杂的视图啊、关键的存储过程啊、典型的报表 SQL 啊还有那些边界数据都给覆盖进去。样本越贴近你生产的情况后面到了全量阶段不确定的东西就越少。第五个把问题关掉的标准给约好。一个问题它绝对不是“有人在群里回过话了”就算关掉了。它得同时满足几个条件才行。得有处理的方案得有修改的记录还得有回归跑出来的结果。而且还得明确说清楚这玩意儿到底影不影响切换的窗口。五、协同架构的边界与客观看法搞了“云端服务”它并不会自己就把迁移的风险给变没。如果说源库的权限本来就乱七八糟的应用连个日志都没有业务那边也说不清口径。那不管你用什么工具最后算出来的评估肯定都是不全的。而且自动转换它也是有边界的。碰到那种牵扯到业务语义的、有外部接口的还有特别复杂的存储过程。这些东西还是得靠开发和 DBA 坐在一起商量着来判断。还有一点我也不会觉得说用云端管项目就是把敏感数据给传到云端去了。在真去部署之前你得搞清楚数据到底是存在哪的传输的时候有没有加密脱敏的策略是什么账号权限怎么分还有审计有什么要求。对于那种压根就不能出网的环境你就得按产品支持的那种方式搞离线部署或者隔离部署。然后让安全团队的人来确认过才行。你要去理解金仓数据库还有 KingbaseES 的价值就得把它放在这种完整的工程链路里面来看。它想干的事情不光是为了证明说这个数据库能把数据收进来。而是说它想让评估的结果啊、迁移的脚本啊、校验的记录啊还有上线时候的支持都能让团队里的人一起拿来用。KDMS 就是通过云端的底账、现场的采集再加上 DBA 的服务把这几个环节给串起来了。这种玩法呢就特别适合那种好多人一起干、得分批次迁而且还得一直盯着进度的大型替换项目。六、我对数据库迁移工具的四个判断第一个嘛我就看它能不能把应用层也给管起来。别光盯着表和索引导进去的速度有多快。第二个看它出来的评估结果能不能把工作量啊、风险啊、谁负责啊这些东西给量化了。别就给一句轻飘飘的“兼容”就完事了。第三个看好几个人一起干的时候它能不能把版本啊、日志啊、验收的证据啊给留住。这项目能不能顺顺当当交接给别人。第四个看出了问题的时候有没有人能在线上给你支招还有有没有一条真能跑得通的回退路子。说到底数据库迁移工具它伺候的其实是一项工程。KDMS 搞的这个“云端服务”的思路就是让工具从原来那一堆单机脚本的集合变成了一个团队可以一起用的项目平台。对于大型信创项目来说迁移成功它不光是说目标库上线了就完了。它更意味着说你用的这套方法事后是可以拿来复盘的是可以被审计的。而且在下一次做项目的时候你还能接着用。七、把协同结果留成可复查数据为了不让云端协同最后又变成另一份没人看的“大 Excel”。我会在任务台账里面给它们保留最起码的结构化字段。下面这个建表的语句呢它其实仅仅是表达一种管理的思路。在真实项目里你可以把它对应到 KDMS 里面的任务啊、批次啊还有问题对象上去。CREATETABLEmigration_task_log(task_idBIGINTPRIMARYKEY,batch_noVARCHAR(32)NOTNULL,source_objectVARCHAR(256)NOTNULL,task_typeVARCHAR(32)NOTNULL,owner_nameVARCHAR(64)NOTNULL,statusVARCHAR(16)NOTNULL,source_versionVARCHAR(32)NOTNULL,updated_atTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMP,evidence_uriVARCHAR(512));SELECTbatch_no,status,COUNT(*)AStask_count,COUNT(evidence_uri)AStask_with_evidenceFROMmigration_task_logWHEREsource_version:source_versionGROUPBYbatch_no,statusORDERBYbatch_no,status;evidence_uri这个字段呢它可以指向你的转换日志也可以指向回归的结果或者是审批的记录。那些没有证据的“已完成”任务就会被单独给挑出来。这时候项目经理就不用光看那个颜色去猜进度了。等端侧又重新采了一次之后呢我还会去跑一次对象数量的差异检查。得先把没采全的问题给揪出来然后咱们再去聊转换率有多高SELECTobject_type,source_count,collected_count,source_count-collected_countASmissing_countFROMmigration_inventory_snapshotWHEREsnapshot_id:snapshot_idANDsource_countcollected_countORDERBYmissing_countDESC;这个检查啊它没法替代你去抽样看对象也没法替代你去做依赖分析。但是呢它能把那些最明显的断点尽可能早地给你暴露出来。