数据库迁移最麻烦的，不是迁，而是动手之前心里没底
做数据库迁移这些年，我越来越觉得，一个项目最危险的阶段往往不是正式迁移，而是迁移之前。
比如一个 Oracle 系统准备切到金仓，项目刚启动的时候，领导最关心的通常就几件事：到底能不能迁？要改多少代码？大概多久能做完？上线之前还有哪些坑？
这几个问题听起来简单，真正要回答好其实很难。 
数据库里可能有几百张表、几十上百个存储过程，还有视图、触发器、序列、函数。应用代码里可能又散落着大量 SQL。靠 DBA 和开发一个个翻，当然也能做，但这种方式最大的问题不是慢，而是很难确定自己有没有漏。
以前做迁移项目的时候，经常会遇到这种情况：前期看起来兼容性还不错，真正开始改造以后，才发现某个存储过程里用了特殊语法，或者应用代码里藏着几条平时不走的 SQL。
这些问题如果早一点发现，其实都不算大问题。
怕的就是到了联调甚至上线前才发现。
所以我现在看数据库迁移，第一件事已经不是"怎么搬数据"，而是先把家底摸清楚。
以前做迁移评估，确实比较依赖经验
传统做法大家应该都比较熟悉。
先导一批 DDL 出来，看表结构和数据类型；再把函数、存储过程、触发器这些对象过一遍。业务系统里的 SQL，则让开发自己搜代码，或者等测试阶段慢慢暴露。
有经验的 DBA 确实能很快判断出很多问题，但再有经验，也架不住对象多。
尤其是存量系统。
一个系统维护五六年以后，里面经常会存在大量历史代码。有些 SQL 一年都不一定执行一次，有些存储过程甚至没人敢删，因为谁也不知道还有没有地方在用。
这种项目如果完全靠人肉评估，很容易出现一个问题：
你知道自己看到了什么，但你不知道自己漏了什么。
这也是我觉得 KDMS 这类迁移评估工具真正有意义的地方。
它不是替 DBA 做决定，而是先把原来靠人肉摸排的东西系统化。
按照 KDMS 用户手册的说明，它会提前采集源数据库中的表、视图、触发器、约束、序列、函数、存储过程等对象，然后评估这些对象迁移到 KES 后的兼容情况和改造工作量。除了数据库对象，它还可以从静态代码或者程序运行过程中采集 SQL，用来检查业务 SQL 是否存在兼容问题。
这件事其实非常关键。
因为数据库迁移从来不只是"把表迁过去"。
真正费时间的，往往是数据库对象和应用 SQL。
KDMS做的事情，可以理解成先给系统做一次"体检"
如果把整个流程说得简单一点，大概就是三步：
第一步是采集。
数据库侧可以采集表、视图、触发器、约束、序列、函数、存储过程这些对象。手册里还特别说明了一点：数据库采集客户端不会读取和采集业务数据，只采集数据库结构信息。这一点对于生产环境还是比较重要的。
目前手册列出的数据库采集数据源包括 Oracle、DB2、MySQL、SQL Server 和 Sybase。
除了数据库本身，应用代码也可以采。
比如 MyBatis 项目，可以解析 Mapper XML 里的 SQL；普通 SQL 脚本也可以直接打包采集。手册中还提到，SQL 脚本采集目前支持 Oracle、MySQL、DB2、PostgreSQL、SQL Server 和 Sybase 语法。
这其实补上了以前迁移评估里很容易遗漏的一块。
因为很多兼容问题并不在数据库里，而是在 Java 项目的 Mapper、SQL 文件，甚至代码动态拼接出来的 SQL 里。
真正有用的，不是一个"兼容率"数字
我第一次看迁移评估报告的时候，最开始也会盯着那个兼容率。
比如 90%、95%。
但项目做多以后会发现，这个数字其实只是一个概览。
真正有用的是下面那些不兼容对象到底是什么。
假设一个系统兼容率 98%，听起来已经非常高了。但如果剩下的 2% 恰好是支付、订单或者核心账务相关的存储过程，那这个 2% 可能比另外 98% 都麻烦。
所以迁移评估不能只看一个百分比。
KDMS 评估完成之后，可以查看兼容度、失败数据以及具体对象的兼容结果，同时还能下载评估报告，用来估算工作量和制定迁移计划。
我更习惯把它当成一个"问题清单"。
迁移真正开始之前，把问题先拆出来：
哪些对象可以直接处理；
哪些 SQL 需要修改；
哪些问题要开发配合；
哪些属于风险比较高的数据库特性；
哪些可以等工具自动处理，哪些必须人工确认。
当这些东西都能列出来以后，项目计划才有意义。
不然所谓"预计两周完成"，很多时候只是一个比较好听的数字。
我比较喜欢KDMS的一点，是发现问题以后还能继续改
迁移评估工具如果只能告诉你"这里不兼容"，其实只能算完成了一半工作。
真正实用的工具，应该允许你把问题继续处理下去。
KDMS 在这一点上做得比较完整。
在评估对象里发现 SQL 不兼容后，可以直接进入 SQL 编辑界面，修改语句以后执行校验。手册中描述得很明确：编辑界面会显示不兼容信息，修改 SQL 后可以点击执行校验。
如果校验通过，还可以继续保存。
保存之后，该语句的评估结果会变成兼容，同时总体兼容度也会重新计算。
这个流程我觉得比单纯生成一份报告好用。
因为数据库迁移经常不是一次性完成的。
实际过程通常是：
发现问题 → 改 SQL → 再验证 → 再发现问题 → 再调整。
如果每次都得手动导出、拿到目标库测试、失败以后再回来改，效率会很低。
把"修改---校验"提前放在评估阶段，很多问题就不用等到正式迁移的时候再碰。
评估报告最好给开发团队一起看
以前数据库迁移很容易出现一种分工方式：
DBA 负责数据库，开发负责应用。
听起来没问题，但迁移过程中这两个部分其实很难完全拆开。
比如一个 Oracle 函数不兼容，到底应该在数据库层改，还是应用代码改？
一条 SQL 用了特定语法，是改 Mapper，还是依赖数据库兼容能力？
这些问题很多时候不是 DBA 一个人能决定的。
所以我现在更倾向于，在迁移前直接把评估结果拆给开发。
数据库对象问题给 DBA；
Mapper 和应用 SQL 问题给开发；
高风险对象单独拉出来讨论。
KDMS 本身也支持数据库采集、应用采集和历史 SQL 采集，评估之后还能查看具体对象。它的产品定位本来就不只是"扫数据库"，而是把数据库和应用两边一起纳入迁移评估。
这样做有一个很现实的好处：
上线前不会突然有人说：
"这个 SQL 我不知道啊。"
还有一个容易被忽略的问题：评估账号
看 KDMS 手册的时候，有一个细节我觉得挺符合生产环境习惯。
它建议采集时单独创建采集用户，采集结束后再删除这个临时用户。
这个看似是个小细节，其实挺重要。
生产库迁移的时候，我个人一直不建议直接把高权限 DBA 账号交给各种迁移工具。
正常做法应该是：
按照需要授予采集权限；
单独创建账号；
采集完成以后回收或者删除。
工具好不好用是一回事，权限边界该有还是得有。
尤其是金融、政务、运营商这一类环境，很多时候权限和审计本身就是迁移方案的一部分。
KDMS不是迁移工具本身，它解决的是迁移前的问题
这个地方很容易混淆。
KDMS 更准确的定位应该是迁移评估。
它解决的问题是：
在你真正迁移之前，把数据库和应用里的兼容问题尽可能找出来，然后把工作量和风险暴露出来。
手册对它的使用场景描述也比较明确：通过兼容性分析和工作量预测，帮助用户和项目团队做迁移决策，同时减少大量重复的人工操作。
所以我不会把 KDMS 理解成"点一下按钮，数据库迁移就结束了"。
数据库迁移真正落地的时候，后面还是会涉及对象迁移、数据迁移、增量同步、业务验证和最终切换。
如果系统还需要较长时间双跑，或者源库持续产生新数据，那么增量同步又是另外一个问题。
你提供的 KFS 材料里，比较值得注意的是它强调了源端并行解析、多通道并行入库以及事务顺序控制，核心目标还是在大数据量情况下兼顾同步吞吐和事务一致性。
所以真正做一个完整迁移项目时，我会把事情拆成几个阶段：
text
迁移评估
↓
兼容性改造
↓
结构和历史数据迁移
↓
增量同步
↓
业务验证
↓
正式切换KDMS 主要解决最前面的"评估"和一部分兼容性改造问题。
而恰恰就是这个阶段，决定了后面的项目到底是有计划地推进，还是一路踩坑。
为什么我现在越来越重视迁移前评估
以前我也觉得，数据库迁移主要看 DBA 水平。
数据库熟一点，SQL 熟一点，遇到问题改就是了。
后来项目做多了才发现，真正影响进度的，经常不是某个技术问题有多难，而是这个问题什么时候被发现。
上线前三周发现一个兼容问题，基本没什么。
上线前三个小时发现，那就是另外一个故事了。
所以迁移评估真正的价值，并不是给你一个漂亮的兼容率。
而是尽量把原本会在迁移中后期暴露的问题，提前到项目刚开始的时候。
哪怕最后发现有一百个问题，也比上线当天突然冒出来三个问题强。
因为前者叫工作量，后者叫事故。
最后说几句
如果让我现在再做一次 Oracle、MySQL、DB2 这类异构数据库迁移，我基本不会一上来就安排开发改代码，也不会直接开始迁数据。
第一件事还是做评估。
先看数据库里到底有哪些对象；
再把应用 SQL 尽量扫出来；
看看哪些能直接迁；
哪些需要人工改；
然后再根据结果排时间和人力。
KDMS 对我来说最大的价值其实不是"自动化"三个字，而是它把以前比较依赖 DBA 个人经验的迁移前摸底，变成了一件可以被统计、被检查、被反复验证的事情。
数据库迁移最怕的从来不是问题多。
最怕的是，你以为没问题。