聊聊国产化替换：好用数据迁移工具KDMS怎么帮咱们搞定评估难

聊聊国产化替换：好用数据迁移工具KDMS怎么帮咱们搞定评估难

其实干咱们IT这行的，大家都知道，现在搞国产化替换是个大趋势。原来用的都是Oracle、DB2这些国外的商业库，现在要换成国产库。那这里头最头疼的一个问题是啥呢？就是数据怎么搬，代码怎么改。这就是咱们常说的数据迁移问题。这事儿其实挺麻烦的。你想啊，一边是业务在跑，一边是要评估能不能换、怎么换。今天咱们就聊聊KDMS这个评估软件，看看它是怎么解决迁移评估这个麻烦事儿的。

一、 咱们搞迁移项目，最头疼的其实是"摸底"

1.1 老办法评估，往往仅仅只是靠经验碰运气

其实咱们做迁移项目的，最怕的就是项目刚开始那会儿。也就是评估阶段。这个时候，老板问你，这个库迁过去要多久？有多少代码得改？风险大不大？你一听就头大。为啥呢？因为你不知道里面到底有啥。

通常来说，以前咱们怎么评估呢？就是连上源库。然后随便挑几张表看看。或者找开发要一两个存储过程看看。然后根据自己的经验，拍个脑袋。觉得这个库结构挺简单的，应该好迁。那个库存储过程多，估计得改一个月。这其实就是一种经验估算。也就是凭感觉。这种情况的话，误差往往特别大。你以为改一周就行了的，最后可能搞了一个月还没弄完。因为里头有些隐藏的坑，你肉眼根本看不出来。

1.2 风险不可控，最后背锅的往往是咱们干活的

评估不准，那就意味着风险不可控。这其实是个大问题。那为什么会这样呢？原因在于你没有把所有的对象都扫一遍。源库里的表、视图、存储过程、函数，成千上万个。你一个个看，根本看不过来。

那等到真正迁移的时候，突然发现某个视图报错了。或者某个存储过程里用了一个Oracle特有的包，目标库根本不支持。这时候业务就卡住了。业务部门一投诉，老板就来找你。你说是谁的责任？最后背锅的往往是咱们这些干活的DBA或者开发。所以说，评估难、风险不可控，是迁移项目里最核心的痛点。不把这个痛点解决了，后面干活心里都没底。

二、 KDMS是个啥，它怎么解决评估问题

那么，有没有啥好办法能解决这个评估难的问题呢？这就要说到KDMS了。KDMS全称叫Kingbase Data Migration Studio，也就是金仓数据迁移评估工具。它其实就是一个专门用来做迁移前摸底的工具。

2.1 KDMS是怎么连上咱们源库的，安全不

咱们用工具第一担心的就是安全。KDMS连你的源库，其实也就是通过JDBC连。它不需要你在源库装啥乱七八糟的agent。也就是个普通的客户端连接。它连上去之后，主要是去读你的系统表。也就是数据字典。它不去扒你的业务数据。也就是说，它不看你表里存了啥具体内容，只看你这个表是怎么设计的，有哪些字段，类型是啥。这样就不用担心数据泄露的问题。

连上之后，它会自动采集源库里的对象信息。像Oracle这种库，它能把你的表、视图、存储过程、函数、包、触发器啥的，全都给扒拉出来。采集完之后，它会在本地存一份。接着就开始分析了。

2.2 自动化评估是咋跑起来的，背后的逻辑

它评估的逻辑其实不复杂，但工作量特别大。它是把源库的对象，一个一个地去跟目标库的语法做对比。比如你是Oracle的表，它就看你的字段类型，目标库支不支持。你是存储过程，它就把里面的PL/SQL代码拿出来，一行一行地解析。看你的控制流语句，看你的变量声明，看你调用的内置函数。

这玩意儿要是人工干，得累死。KDMS能自动跑，而且跑得挺快。跑完之后，它就会生成一份报告。这就是咱们今天要重点说的《迁移评估报告》。这份报告里头，有兼容度，有改造工作量。这些量化指标，就是咱们做迁移决策的科学依据。不用再拍脑袋了。
#mermaid-svg-EztzwMn8lX0BrmS0{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-EztzwMn8lX0BrmS0 .error-icon{fill:#552222;}#mermaid-svg-EztzwMn8lX0BrmS0 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-EztzwMn8lX0BrmS0 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-EztzwMn8lX0BrmS0 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-EztzwMn8lX0BrmS0 .marker.cross{stroke:#333333;}#mermaid-svg-EztzwMn8lX0BrmS0 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-EztzwMn8lX0BrmS0 p{margin:0;}#mermaid-svg-EztzwMn8lX0BrmS0 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster-label text{fill:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster-label span{color:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster-label span p{background-color:transparent;}#mermaid-svg-EztzwMn8lX0BrmS0 .label text,#mermaid-svg-EztzwMn8lX0BrmS0 span{fill:#333;color:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 .node rect,#mermaid-svg-EztzwMn8lX0BrmS0 .node circle,#mermaid-svg-EztzwMn8lX0BrmS0 .node ellipse,#mermaid-svg-EztzwMn8lX0BrmS0 .node polygon,#mermaid-svg-EztzwMn8lX0BrmS0 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-EztzwMn8lX0BrmS0 .rough-node .label text,#mermaid-svg-EztzwMn8lX0BrmS0 .node .label text,#mermaid-svg-EztzwMn8lX0BrmS0 .image-shape .label,#mermaid-svg-EztzwMn8lX0BrmS0 .icon-shape .label{text-anchor:middle;}#mermaid-svg-EztzwMn8lX0BrmS0 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-EztzwMn8lX0BrmS0 .rough-node .label,#mermaid-svg-EztzwMn8lX0BrmS0 .node .label,#mermaid-svg-EztzwMn8lX0BrmS0 .image-shape .label,#mermaid-svg-EztzwMn8lX0BrmS0 .icon-shape .label{text-align:center;}#mermaid-svg-EztzwMn8lX0BrmS0 .node.clickable{cursor:pointer;}#mermaid-svg-EztzwMn8lX0BrmS0 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-EztzwMn8lX0BrmS0 .arrowheadPath{fill:#333333;}#mermaid-svg-EztzwMn8lX0BrmS0 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-EztzwMn8lX0BrmS0 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-EztzwMn8lX0BrmS0 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-EztzwMn8lX0BrmS0 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-EztzwMn8lX0BrmS0 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-EztzwMn8lX0BrmS0 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster text{fill:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 .cluster span{color:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-EztzwMn8lX0BrmS0 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-EztzwMn8lX0BrmS0 rect.text{fill:none;stroke-width:0;}#mermaid-svg-EztzwMn8lX0BrmS0 .icon-shape,#mermaid-svg-EztzwMn8lX0BrmS0 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-EztzwMn8lX0BrmS0 .icon-shape p,#mermaid-svg-EztzwMn8lX0BrmS0 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-EztzwMn8lX0BrmS0 .icon-shape .label rect,#mermaid-svg-EztzwMn8lX0BrmS0 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-EztzwMn8lX0BrmS0 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-EztzwMn8lX0BrmS0 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-EztzwMn8lX0BrmS0 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 开始自动化评估
连接源数据库
采集源库对象元数据
对象类型分类解析
表结构/字段类型比对
视图SQL语法解析
存储过程/函数PL逻辑解析
生成兼容性清单
计算兼容度与改造工作量
生成《迁移评估报告》

三、 重点看《迁移评估报告》，量化指标怎么帮咱们做决定

前面说了，KDMS最后会吐出一份报告。这份报告才是咱们真正要用的东西。它把那些模糊的"经验估算"，变成了清晰的"数据决策"。咱们来看看这报告里都有啥。

3.1 兼容度算出来，心里就有底了

报告第一眼看到的，就是兼容度。通常是个百分比。比如它告诉你，这个库的兼容度是85%。那你就心里有数了。大部分东西是可以直接迁过去的。那剩下的那15%呢？就是不兼容的部分。也就是需要咱们去改的。

这个百分比是怎么来的呢？其实很简单。假设你的源库里有1000个对象。KDMS扫完以后，发现里面有850个对象，完全不用改，直接就能在目标库建出来。那这个兼容度，基本上就是85%。也就是说，它把一个模糊的概念，变成数学题了。你拿着这个85%去找老板，老板也能看懂。老板就知道，这个项目还是有戏的，不是那种完全推倒重来的活儿。

3.2 改造工作量估算，排期终于不用瞎蒙了

除了兼容度，报告里还有个特别实用的东西，叫改造工作量估算。这个对咱们排期太有用了。以前排期，都是开发人员凭感觉说，这个模块我得搞一周。其实他根本不知道里面有多少坑。

KDMS的报告里，会把不兼容的对象都列出来。然后根据不兼容的程度，给你估一个工作量。比如某个存储过程，里头有3处语法不支持。它可能就估算你需要2个小时去改。如果某个视图，直接就语法报错跑不通，它可能估算你需要4个小时重写。把这些工作量加起来，就得出一个总的时间。比如这个库改造完，需要大概300个人天。那你就可以根据这个，去排项目计划了。这个数据决策，非常科学。

3.3 按对象类型统计，细节拉满，兼容与不兼容一目了然

最让我喜欢的，是报告里那个按对象类型统计的表格。它不是给你一个总数就完事了。它分得很细。它把对象分成了表、视图、存储过程、函数、触发器这些大类。

比如表这一类。源库有500张表。报告告诉你，完全兼容的有480张。不兼容的有20张。这20张里头，可能是因为字段类型不兼容，比如Oracle有个VARCHAR2，目标库可能要用VARCHAR。或者有些分区表的分区策略不支持。

再看视图。视图可能比表不兼容的多一点。因为视图里头有SQL查询嘛。有些Oracle的特殊函数，目标库没有。那视图就得改。

最复杂的是存储过程和函数。这玩意儿里头全是逻辑代码。报告里会明确写出来。比如有100个存储过程，兼容的只有50个，不兼容的有50个。这50个不兼容的里头，有几个是因为控制流语句不兼容，有几个是因为内置包不兼容。它都给你统计得明明白白的。这就是把评估的详细程度，做到了对象级别。你看了这个表，就知道哪块骨头最难啃。

四、 提前识别风险，把坑提前挖出来

其实做迁移项目，最怕的就是遇到突发的风险。也就是那种你事先没料到，突然冒出来卡住你的坑。KDMS的评估报告，能帮咱们提前识别风险。把坑提前挖出来。这功能太救命了。

4.1 风险等级划分，哪些必须改，哪些可以先放着

报告里会对不兼容的对象做个风险等级划分。这个挺好的。不是所有不兼容的东西，都会马上让系统崩掉。有些是致命的。比如某个核心业务的存储过程跑不通。这种就是高风险。属于必须改的。不改业务就断了。

有些是低风险的。比如某个生成报表的视图，里头用了个不影响大局的内置函数。虽然报错了，但不影响核心交易。这种的话，如果时间紧，你可以先放着。后面再慢慢改。有了风险等级划分，你在干活的时候，就能分清主次了。先解决高风险的，再搞定低风险的。这就是一种科学的策略。

4.2 模糊的"经验估算"转变为清晰的"数据决策"到底有多爽

咱们再聊聊这个把"经验估算"变成"数据决策"的事儿。其实这不仅仅是看个数字的问题。它改变了整个项目的管理方式。

以前咱们搞迁移，开发人员一上手，遇到一个报错改一个。最后改到一半，发现改不完了。为什么？因为没估算准。现在有了KDMS的报告，咱们在开工前，手里就有张地图。哪里有雷，哪里有水，报告上都标着呢。

你可以拿着这份报告，去跟开发人员对峙。你说，你看，这个存储过程不兼容，里头用了Oracle的DBMS_LOCK包。目标库不支持。你得用别的方式实现。预计花多长时间？开发一看就明白了。这就叫数据决策。大家都不吵架了。因为数据摆在那儿，客观公正。这就把那种模糊的、扯皮的事情，变成了清晰的、可量化的任务。干起活来效率特别高。

4.3 举个真实的排查例子，说明提前识别风险的好处

我给大家讲个真事儿。之前有个项目，要从一个老库迁到新库。用KDMS一扫。发现有个存储过程，里头用了一段特别老的动态SQL写法。而且还没用绑定变量。这种写法，在目标库上跑，不仅语法报错，就算改通了，性能也会特别差。

如果咱们没做评估，直接迁。等迁完一跑，业务卡死。那时候再去排查，得花好几天。因为业务一卡，大家都急了，各种乱查。有了评估报告，咱们提前就知道这玩意儿有坑。然后咱们就提前安排了一个高级开发，专门去重写这段逻辑。等迁移的时候，这段代码早就改好了。平滑上线，一点事没有。这就是提前识别风险的好处。它给你争取了反应的时间。

五、 KDMS里头那些评估细节，咱们拆开揉碎了看

其实KDMS这个东西，你要是只拿它当个出报告的机器，那就有点浪费了。它里头评估的细节，才是真正有价值的。咱们今天就把这些细节，拆开揉碎了来看看。这也是我在实际项目里，觉得特别好用的几个点。

5.1 表结构评估，不仅仅是看字段那么简单

咱们前面说了，表结构评估，它看字段类型。但其实它看的东西多着呢。你想啊，一张表，除了字段，还有啥？还有约束。主键、外键、唯一键、检查约束。这些它都得评估。

比如有个检查约束，写了个正则表达式。Oracle的正则和目标库的正则，可能支持的语法有点不一样。KDMS就能扫出来。告诉你，这个约束迁过去，可能没法生效。你得手动改改正则。

还有索引。索引的类型。普通的B树索引没问题。如果是Oracle的位图索引，或者函数索引。目标库可能不支持位图索引。那它就会在报告里标出来。告诉你，这玩意图是提升查询速度的，迁不过去。你得想别的招，比如建个普通索引，或者改改SQL。这些细节，你要是人工看，一百张表能看花眼。工具一扫，全出来了。这就是自动化的威力。

5.2 视图评估，SQL重写往往是重灾区

视图这块，其实是重灾区。为啥呢？因为视图就是一段SQL查询。很多开发人员，写SQL的时候，特别喜欢用Oracle特有的语法。比如Oracle的CONNECT BY，用来做树形查询。还有那个PIVOT和UNPIVOT，用来做行列转换。

这些语法，在国产库里，有的支持，有的不支持。就算支持，可能也有点细微的差别。KDMS在评估视图的时候，它会解析这个SQL的语法树。它发现你用了CONNECT BY，它就去查目标库的兼容性字典。如果不兼容，它就在报告里给你标红。告诉你，这个视图得重写。用递归查询（WITH RECURSIVE）的方式去改。这就给你指明了改造的方向。不用你自己去瞎猜该怎么弄。

5.3 存储过程和函数评估，PL/SQL到PL/pgSQL的跨越

最难的，也是最能体现工具实力的，就是存储过程和函数的评估。这块的逻辑太复杂了。从Oracle的PL/SQL，迁到比如KingbaseES的PL/pgSQL。虽然都是过程化SQL，但里头差别不少。

比如变量声明。Oracle里头声明变量，是变量名 数据类型;。但是在PL/pgSQL里头，有些地方是反过来的。如果你没改，那就报错。KDMS能把这些语法差异都扫出来。

再比如异常处理。Oracle里头抓异常是WHEN OTHERS THEN。目标库也支持。但是Oracle里头有个SQLERRM，用来获取错误信息。目标库里可能得用别的方式获取。这些细微的差别，报告里都会给你列出来。它会告诉你，在第几行，用了什么不兼容的语法。建议你怎么改。这简直就是个代码审查工具。开发人员拿着这个报告去改代码，效率能提高好几倍。

5.4 触发器和包的评估，最容易遗漏的角落

触发器和包，这些对象在系统里往往不起眼，但一旦出问题，影响很大。Oracle的包，也就是Package，可以把存储过程和函数打包在一起。但是像PostgreSQL或者KingbaseES这种库，它没有包这个概念。它只有模式。那怎么迁？这就不是简单的改改语法能解决的了。这是个架构层面的问题。

KDMS遇到这种情况，它会在报告里明确指出。源库有10个包，目标库不支持包。改造工作量巨大。建议你把包里的存储过程，都拆到模式级别下去。这种提示，就非常有价值。它让你提前知道，这块骨头很难啃，得提早安排人手。触发器也是一样。有些行级触发器，在Oracle里能跑，在目标库里可能因为上下文环境不一样，跑出问题。这些都能提前评估到。这就是KDMS的实力。

六、 统一的管控平台和报告输出，长啥样，好用不

其实KDMS这个东西，它不只是一个后台跑批的命令行工具。它有个挺好用的Web界面。也就是管控平台。在这个平台上，你能把评估的过程管理起来。

6.1 可视化Web管理，点两下鼠标就能出报告

你登录Web界面后，建个评估任务。填上源库的IP、端口、账号密码。再选个目标库的类型。比如源库是Oracle，目标库选金仓的KingbaseES。然后点一下开始评估。

接着它就在后台跑上了。你能在界面上看到进度条。比如正在采集表，正在解析存储过程。跑完之后，报告就直接在网页上展示了。你可以点进去看。非常直观。不用去服务器上敲命令找日志。这个对于不擅长写命令行的同事来说，特别友好。而且报告还能导出成Excel或者PDF。你可以拿去给老板汇报，或者发给开发团队去对照着改。

6.2 评估报告的详细程度，按对象类型统计兼容与不兼容的数量

咱们再回过头来看看这个报告的详细程度。前面简单提过，按对象类型统计兼容与不兼容的数量。这里咱们再展开说说。因为这个真的是咱们做决策最核心的依据。

报告里头，会有个大表格。一行一行地列着。

比如：

对象类型：表。总数：500。兼容：480。不兼容：20。兼容率：96%。

对象类型：视图。总数：200。兼容：150。不兼容：50。兼容率：75%。

对象类型：存储过程。总数：100。兼容：40。不兼容：60。兼容率：40%。

你看这个表格，一眼就能发现问题。表的问题不大，大部分能直接迁。但是存储过程只有40%兼容。也就是说，大部分存储过程都得改。那这个改造工作量肯定小不了。你在排期的时候，就得给存储过程多留点时间。

这就是把模糊的经验，变成了清晰的数字。你跟开发沟通的时候，就可以直接说，这60个存储过程，你们看看，平均一个得改多久？开发一看，心里也就有数了。这比你说"存储过程估计有不少得改"，要清晰得多。这就叫科学依据。

6.3 不兼容对象的详细列表，直接指到哪一行代码

除了统计数字，报告里还有个更详细的清单。也就是不兼容对象的列表。这个列表才是开发人员最爱看的。

你点开那个不兼容的存储过程列表。它会列出每个存储过程的名字。然后后面跟着不兼容的原因。比如它会说，PROCEDURE_CALC_SALARY这个存储过程，在第45行，使用了不支持的DBMS_OUTPUT.PUT_LINE语句。在第120行，使用了不支持的FORALL批量绑定语法。

你看，它直接指到哪一行代码了。这就太省事了。开发人员都不用去全文搜索。直接打开代码，跳到45行，改掉。跳到120行，改掉。对于视图也是一样，它会告诉你，视图里用了个ROWNUM，目标库不支持，得用LIMIT或者ROW_NUMBER()去替代。

这种精确到行的报告，能极大地减少排查问题的时间。这就是把改造工作量降到了最低。也就是把迁移项目的风险，降到了最低。

七、 一点个人的碎碎念和总结

其实说到底，咱们搞IT的，最怕的就是不确定性。迁移项目里充满了不确定性。源库里到底有啥？不知道。代码能不能跑通？不知道。要改多久？不知道。这就是评估难、风险不可控。

KDMS这个数据迁移评估工具，其实就是帮咱们把不确定性变成确定性。它通过自动化评估，把整个源库扒了个底朝天。然后生成量化报告。告诉你兼容度是多少，工作量是多少，坑在哪儿。

它把模糊的经验估算，彻底丢进了垃圾桶。取而代之的是清晰的科学依据。你拿着这份《迁移评估报告》，就能做决策了。能上就上，不能上就先改。风险都在掌控之中。这对于咱们做企业层级里的国产化替换来说，是个必不可少的利器。

其实工具也就是个工具。它不能帮你把代码全写了。但它能帮你指明方向。让你少走弯路。在咱们这个时间紧任务重的国产化大潮里，能少走弯路，就是最大的节省。所以，如果你正准备搞数据库迁移，不妨先找这类评估工具扫一扫。心里有底了，干活才不慌。好了，今天就聊到这儿吧，希望对大家有点用。