一、先说背景：为啥我会天天跟这软件打交道
干数据库开发这行很久了。去年公司搞国产化替代，要把几个跑了快十年的Oracle业务库，整体迁到金仓KingbaseES上面去。这个项目里我负责的，就是数据这一摊子事。
啥叫数据这一摊子事呢？说直白点，就是怎么把老库里的表结构、数据、索引这些东西，完整地弄到金仓里去，还不能出岔子。这个活从选工具、写方案，到实际动手迁、验数据，前前后后折腾了一年多。
金仓的数据集成软件，主要就是两个工具。一个叫KDTS，全称Kingbase Data Transfer Service，是做数据迁移用的。另一个叫KFS，全称Kingbase FlySync，是做实时数据同步用的。这两个工具，我这一年多算是天天在用，用得多了，有些门道也踩了不少坑。
这篇我就把这些东西一次写清楚。包括这俩软件分别是干啥的、怎么装、实际怎么配、迁移过程长啥样、以及我踩过的那些坑。你要是后面也要做金仓这边的数据迁移或者同步，可以把这篇当一个过来人的操作笔记来看。
先交代下我们的底子，这样你看后面的方案就有参照了。我们的订单系统，跑在Oracle 11g上。库里几个T的数据，最大的一张明细表三亿多行。业务是7乘24小时的，白天压根不能动。能给的停机窗口，也就凌晨那两个小时。这个条件，直接决定了我们后面所有的做法。你要是条件比我们宽裕，那恭喜，下面的做法你可以放宽着用。你要是比我们还紧，那这篇文章你更要细看了。
二、先搞清楚：金仓的数据集成软件都有啥
刚接手这个活的时候，我第一件事就是把金仓家的工具摸清楚。因为你做方案之前，得先知道手里有啥牌，对吧。
金仓的数据集成软件，核心就是KDTS和KFS这两个。它俩名字看着像，其实干的活不一样。我给你分开说。
先说KDTS。 它是干一次性迁移的。也就是说，你把源库和目标库配好，选好要迁的对象，点一下跑，数据就批量过去了。跑完这个任务就结束了，它不管后面源库又新产生的数据。所以它适合啥场景呢？适合那种可以停机迁的、或者数据基本不怎么变的库。
KDTS分两个版本。一个是单机版，就是个图形界面的客户端程序，解压就能用，装在你自己的电脑上。适合小库，或者临时倒点数据。另一个叫管理版，也有叫服务版的，是B/S架构，装在服务器上，浏览器打开用。管理版支持多任务并行跑、有迁移报告、团队里几个人可以一起用。我们项目上用的是管理版。为啥呢？因为迁几百张表的时候，你不可能一个任务跑到底，要拆好多个任务排着队跑，这个编排的活，管理版干起来顺手。所以我建议你也直接上管理版，别在单机版上凑合。
再说KFS。 它是干持续同步的。部署好之后，源库上每发生一条数据变更，它就抓过来，近实时地弄到目标库里去。只要链路不断，两边的数据就一直保持接近一致。它适合啥场景呢？适合那种新老库要并行跑一段时间的切换。也就是大家常说的不停机割接。
那为啥我们两个都要用呢？这里我展开讲一下，这个思路你可以直接抄。
我们的业务不能长停机。那张三亿行的明细表，就算用多线程往金仓里灌，全量灌完也要七八个小时。凌晨两小时的窗口，根本不够。那怎么办呢？分步走。
第一步，挑一个业务低峰的白天，先跑一遍全量迁移。注意这时候老库业务还在跑，所以迁过去的数据，只是那个时刻的快照。之后老库新产生的变更，新库是没有的。第二步，上KFS。让它从全量迁移的那个时间点开始，把老库的变更一条条同步到新库。等同步延迟慢慢追平、稳定在秒级之后，两边数据就基本一致了。第三步，挑一个凌晨，停掉老库的写入，等KFS把最后那点变更追完，做数据核对，没问题就把应用切到金仓上。整个过程中，业务实际感知到的停机，也就十来分钟。
这套流程走下来，KDTS负责搬存量，KFS负责追增量。两个工具各干各的活，配合得还挺顺。后面第三到第六节讲KDTS，第七节讲KFS，你可以按需跳着看。
三、KDTS怎么装：过程和几个注意点
先说安装。这部分我尽量写细一点，因为这里面有几个点，是文档里说得不算清楚的，我是踩完了才明白。
第一件事，查JDK。KDTS是Java写的，要JDK 1.8以上。你先在机器上敲个java -version看看。要是没有，或者版本低了，先去把JDK装好。别嫌这一步麻烦。我们有个同事，装的时候跳过这步检查，后面服务起不来，报了一堆看不懂的错，排查半天，最后发现就是JDK版本的事。这种低级问题最浪费时间，因为你会往深了查，反而不信是环境的事。
第二件事，license。KDTS跟金仓的商务授权是走的，你拿到安装包的时候，会一起拿到license文件。这个文件要放到它指定的目录下面。放的位置不对，或者文件过期了，服务能起，但是跑任务的时候会报授权错误。我们测试环境有一回就是license过期了没注意，任务跑到一半断掉，报错信息还挺吓人。所以养成个习惯，升级或者续期之后，先跑个小任务验证下授权，再干正事。
然后是解压安装包。单机版最简单，解压完，目录里有个启动脚本，Windows下是bat的，Linux下是sh的，双击或者敲一下就起来了。管理版要多一步，就是起服务。服务起来之后，用浏览器访问它的管理页面。具体的默认端口，你拿到哪个版本，就看对应版本的文档，不同小版本有差别。我就不写死一个数了，免得给你带偏。
装完先别急着建任务。我建议你先干两件事。
第一件，把要迁的源库账号权限过一遍。Oracle这边，迁移用的账号，得能查数据字典，能读所有要迁的表。要是权限不够，连对象列表都拉不全。这种情况你还以为库里没这个东西，其实是账号看不着，方向就查偏了。
第二件，在金仓那边，提前把目标库、模式、表空间规划好。别到时候一股脑全塞进默认模式里。表空间按业务分一分，日志和数据分开，这些是老规矩了，迁之前规划好，省得迁完了再挪，那可就费劲了。
四、KDTS迁移Oracle到金仓：完整走一遍
装好之后，就是建迁移任务。我按我们实际的操作顺序讲，一共五步。
第一步，配源端和目标端。 在管理页面里，先把两端的数据源配好。源端就是Oracle，填主机、端口、服务名、账号密码。目标端是金仓，填主机、端口、数据库名、模式、账号密码。金仓默认端口是54321，你们要是改过，就按实际的填。配完有个测试连接的按钮，点一下，确认能连通再往下走。这一步要是都连不通，去查网络策略、防火墙，先把路修通，再谈别的。
第二步，选要迁的对象。 KDTS会把源库里的对象拉成一个清单，你勾选要迁哪些。可以按表勾、按用户勾，也可以整个库全选。
这里面有个事要注意：存储过程和函数这块，我建议你降低预期。Oracle的PL/SQL跟金仓里的过程语言，语法上大体能对上，但肯定不是百分之百。逻辑复杂的存储过程，迁过去大概率要人工再改一轮。我们几百个存储过程，KDTS迁完之后，能直接跑的占七成左右，剩下三成是人工改的。所以你做工作量估算的时候，这块一定要算进去。我们当时就是低估了这块，最后两周全是人力在补存储过程的修改，加班加到眼冒金星。
第三步，配类型映射。 这一步最重要，没有之一。Oracle的字段类型，到金仓里对应成什么类型，KDTS有一套默认的映射规则。大部分默认的是对的，但有两个地方，我强烈建议你手动改。哪两个呢？
一个是DATE。Oracle的DATE类型，是带时分秒的。KDTS默认给映射到的那个日期类型，精度只到天。也就是说，你要是不改，迁过去的数据，时分秒全变成零点了。我们第一轮测试迁移的时候就没注意这个。第二天业务侧跑报表，说所有的时间字段都变成整点了，查了半天才定位到是类型映射的事。改成映射到timestamp，精度到微秒，问题解决。这种坑的讨厌之处在于，它不报错。数据悄悄就不对了，你不上业务对账，根本发现不了。
另一个是NUMBER。Oracle的NUMBER不带精度的话，默认映射到金仓的numeric，这个没问题。带精度的NUMBER(p,0)，映射到整型，也没啥问题。但你要留意小数位数，NUMBER(p,2)这种金额字段，映射过去精度别弄丢了。金额要是差一分钱，业务那边是要报警的。我建议你在测试环境，把每张核心表的字段映射清单过一遍。别嫌费事，这一小时能帮你省后面好几天的排查。
第四步，配高级选项。 主要是这么几个参数。迁移线程数，控制并发。批次大小，控制一次灌多少行。还有错误处理策略，出错是跳过还是直接中止。
这几个参数，我的经验是，别贪大。线程数不是越多越好。你开十六个线程，源库读、网络传、目标库写，哪一环先顶不住，都会报错，而且报错的位置还不固定，今天源库超时，明天目标库锁等待，查起来特别乱。我们一般是从4线程、批次5000开始试，观察迁移的吞吐和两边的负载，再慢慢往上加。加到吞吐不再涨、负载也还健康，那就是合适的位置。你自己的环境，得自己摸一轮，摸出来的参数才是好参数，别人的数字只能参考。
第五步，跑任务，看报告。 点执行之后，可以实时看进度。每个对象迁了多少行、速度多少，都有显示。跑完会出一个迁移报告，告诉你成功多少对象、失败多少、跳过多少。
这里我要单独提醒一句：别只盯着成功数看。报告里有个警告清单，一定要逐条过。有些警告是索引没建上，有些是字段类型降级了，有些是数据被截断了。这些警告不影响任务显示成功，但个个都是雷。我们后来养成的规矩是，迁移报告里除了success，warning和error一律要看完、处理完、记录完，这个任务才算结束。谁的迁的谁签字，出了事能找到人。这套规矩听着繁琐，但真给你省命。
五、实例：三亿行的sys_order_detail是怎么迁的
前面讲的是通用流程，这里讲个具体的。我们那张最大的表，sys_order_detail，订单明细表，三亿多行，在Oracle里是分区表，按月份分的区。相关的还有sys_order_master订单主表，八千多万行，sys_user_info用户表，千万级。这几张表是我们迁移工作的主战场。
一开始我想着省事，直接选这张sys_order_detail，一个任务跑完。结果试跑的时候就发现不行。为哈呢？单表单任务跑，它吃不满并行资源。三亿行的量，估了下时间要十来个小时，太慢了。
后来的做法是拆。既然源表是按月分区的，那就按分区拆任务。一个分区一个迁移任务，几个任务并行跑。同一个分区内部，KDTS自己还有线程级的并行。这么一拆，整体吞吐上来了一大截，最后压到了四个小时以内。
这里有个细节要提。按分区拆任务的话，目标端的表你得先建好。也就是说，分区表的结构迁移，单独用一个任务先跑，只迁结构不迁数据。然后数据按分区灌。最后索引这些，也建议单独一个任务，在数据灌完之后再建。
为哈索引要最后建？你想啊，你要是先把索引建好，再往里灌三亿行数据，每灌一行，索引都要跟着维护一次，那个速度就没法看了。先灌数据后建索引，整体能快非常多。外键约束同理，也放到最后。不然导入的时候，每行都要过一遍外键校验，又慢又容易报错，报错了你还得逐条去看是数据问题还是顺序问题。这是迁大表的一个基本套路，KDTS里你可以通过排任务的执行顺序来控制，操作上就是拖一拖先后。
那个BLOB字段多的表，就是存图片的那几张，单独说下。这种表迁移特别慢，因为大对象走的是另一套读写逻辑，跟普通行数据不是一码事。我的做法是把它们单独拆成独立任务，批次调小，线程可以适当多开点，挑业务低峰跑。而且要提前跟业务打好招呼，这几张表是长尾，别的表都迁完了，它们可能还在跑。别到时候人家以为迁完了，你这还挂着呢。
最后一条，把每个任务的耗时记下来，形成一张表。这张表后面有大用。你在评估割接窗口的时候，靠的就是这些实测数据，不是拍脑袋。我们最后给领导汇报割接要多久，说得出具体数字，靠的就是这张表。这也是我建议你从第一次演练就开始记录的原因，数据攒多了，你说话就有底气。
六、数据校验：迁完怎么确认没丢数据
迁移跑完，不等于活干完了。怎么证明数据是完整的？这块我花的心思，说实话比迁数据本身还多。因为你跟业务方对数据，人家就认你的校验结论，你说迁完了没丢，得拿东西出来证明。
我总结下来，校验分四层，一层比一层细。
第一层，对象核对。 两边表的数量对不对、视图数量、索引数量、序列数量，先对一遍。这个用SQL查系统字典就能做，几分钟的事。数量对不上的，直接去迁移报告里找原因，基本都能对上号，多一半是warning清单里躺着的。
第二层，行数核对。 每张表，两边各跑一个count。这个看着简单，但大表count很慢。三亿行的表，两边各count一遍，要跑挺久，还得挑低峰跑，不然把库跑出问题。所以我们是这样处理的：核心表，老老实实count，跑再久也等，没商量。小表，也count，反正快。中间那部分，用Oracle统计信息里的行数做个参考值先比对着，最后割接窗口里再用真实count兜底。分层次处理，精力花在刀刃上。
第三层，内容校验。 行数一样，不代表内容一样。做法是做聚合比对。比如金额字段，两边各sum一遍，对总数。时间字段，两边各取max，对最新值。再进一步，按天分组，每天的sum和count都比一遍。这种分组聚合比对，能发现很细的问题。我们有一回就是靠它，发现一张表有几千行的时间字段丢了时分秒，就是前面说的DATE映射那个坑，改了映射重新迁才解决。要不是按天比对，这种问题混在总数里根本看不出来。
第四层，抽样比对。 随机抽一批主键，两边按主键把整行捞出来，一个字段一个字段地比。抽样量不用太大，几百到几千行就够，但覆盖面要广。各个时间段的、各种业务类型的，都要抽到。这步主要防的是那种行数对、总额对、但个别字段错位的低级问题。这种问题占比很小，但出了一个，查起来要人命，所以这层不能省。
除了这四层，还有一个特别容易漏的：序列。金仓这边自增靠序列。迁移的时候，表数据是迁过去了，但序列的当前值，不一定跟表里实际的最大值对上。要是没对上，应用一切过来，插入新数据，序列吐出来的值跟已有数据撞了，直接主键冲突报错。所以割接前，要把所有序列的当前值重置一遍，重置成对应表里当前最大值加一。这个动作不难，就是容易漏，因为它不在"迁表"这个流程里，是流程外的活。我们把它写进了割接检查清单，谁值班谁照单执行，一条条打勾。
sql
-- 割接前把序列当前值重置到表内最大值，防止插入撞主键
SELECT setval('seq_sys_order_detail', (SELECT MAX(order_id) FROM sys_order_detail) + 1);
SELECT setval('seq_sys_order_master', (SELECT MAX(order_id) FROM sys_order_master) + 1);这条SQL不复杂，麻烦的是序列多。我们库里两百多个序列，一个一个敲肯定不行，得写个循环批量跑，跑完再抽几个手工验。总之记住一条：序列重置这个事，宁可多查一遍，不可漏一个。
七、KFS实时同步：不停机切换的关键
前面说过，光靠KDTS全量迁移，新老库之间会有个数据缺口。补缺口靠KFS。这块我详细讲下，因为它比KDTS门槛高一些，坑也更隐蔽。
先说我对它原理的理解，用大白话说。数据库改数据的时候，自己会记日志，这是数据库的本职工作，跟KFS没关系。KFS干的事，是在源端把这些日志读出来，把里面的数据变更，翻译成它自己格式的一个个事件，先落到本地的队列文件里，然后传到目标端，在金仓那边照着事件再执行一遍。整个链路，业务代码一行都不用改，应用那边根本感知不到中间有个同步在跑。这一点我觉得是最舒服的。做同步最怕的就是要改业务代码，那玩意一改，测试、发版、回滚方案全得跟着来，牵扯太多。
部署上，它是两端都要装东西。源端装一个同步服务，目标端装一个接收回放的服务，另外有个管理控制台，管着所有的链路。配置文件是properties格式的，要配的东西大概这么几类：源库的连接信息、要同步哪些表、日志相关的参数、本地队列的存放目录、传输用的端口。具体的参数名，你拿到哪个版本就看哪个版的文档，我不在这里凭印象写参数名给你，怕给你带偏。反正照着官方文档的样例改，一小时的活，不难。
但有几个坑，文档里写得轻描淡写，实际很要命，我给你划下重点。
第一个，Oracle源端的归档日志必须开。 KFS解析的是日志，日志都没归档，它读啥？另外还得开追加日志，就是让日志里带上完整行信息的那个功能。不开的话，解析出来的更新语句，只有关键列没有全部列，同步到目标端数据就不完整。我们测试环境就踩过这个：UPDATE同步过去了，非关键列没更新，两边数据悄悄不一致，查了两天才查到根上。这两个开关，装KFS之前就检查好，五分钟的事，省你两天的排查。
第二个，大事务。 老库上要是跑了一个几百万行的大事务，比如大批量UPDATE，KFS这边的延迟会猛涨。因为它要等这个事务完整提交了，才能把这一大坨变更往目标端放。所以后来我们立了规矩：割接前两周，老库上禁止跑大批量DML。要批量改数据的，要么提前做，要么拆成小批次做。规矩立了之后，延迟就再没飙过。
第三个，DDL默认不同步。 同步期间，要是有开发在老库上加了字段，KFS默认是不会把这个加字段的动作带过去的。新库表结构没变，数据同步过来就会报错，或者悄悄出问题。所以同步期间的老库DDL，要走变更管理，人工在新库同步执行一遍。这个要跟团队提前说好规矩，并且写到值班手册里。你不信的话可以试试，总有开发忘了报备，半夜给你来一手。
链路跑起来之后，日常就是看延迟。控制台上能看到两端之间的延迟，正常稳定在秒级。要是延迟持续上涨，就得查了。一般就是源端有大事务，或者目标端回放堵住了。延迟这个指标，强烈建议接到你们的监控告警里，别靠人盯。人盯是盯不住的，周末的时候尤其盯不住。
八、踩坑合集：我把交过的学费给你列一遍
前面零零散散说了不少坑，这里再集中整理一遍，加上几个没讲到的。你要做迁移，开工之前把这一节整个读一遍，能少走很多弯路。
坑一，DATE丢时分秒。 前面说过了，类型映射里改成映射到timestamp。这是我觉得杀伤力最大的一个坑，因为不报错，数据悄悄就不对了。补救也麻烦，得重新迁。好在它有个特征：报表里的时间全是整点。业务一反馈这个，你就该条件反射想到它。
坑二，字段长度截断。 源库Oracle是GBK字符集，目标金仓是UTF8。一个汉字，GBK占两个字节，UTF8占三个。Oracle那边varchar2(100)是按字节算的，能装五十个汉字。到金仓这边要是还按一百个字节建，装到五十个汉字的时候就要报字段值太长。这种错好歹是显性的，插入会报错，能发现。处理办法是建表的时候把长度放宽，我们一般乘以1.5。要是迁移日志里批量出现"值太长"这类提示，就往字符集这个方向查，八九不离十。
坑三，序列没重置。 前面讲过了。主键冲突的报错一看就懂，但排查的人要是不知道有这个坑，容易怀疑人生，以为迁丢了数据。割接清单里必须有它。
坑四，时区。 带时区的时间类型，两边客户端时区要是不一致，查出来能差八个小时。我们碰到过一次，两边各说各的理，都说自己是对的，最后发现是工具连接的时区没统一。处理办法是统一约定：所有连接串里显式指定时区，应用、工具、脚本全统一。这个事不复杂，但要让所有人都知道，不然总有人栽进去。
坑五，大小写。 Oracle对象名默认全大写，金仓默认是小写。我们用的模式是大小写不敏感的，也就是说SQL里表名写大写写小写都能对上，还算省心。但要是有应用的SQL里硬写了带双引号的大写表名，那就有讲究了，你得提前测。这个坑我们项目里没炸，但我知道有兄弟单位炸过，这里给你提个醒。测试用例里专门留几条带引号大写的SQL，跑一遍，心里踏实。
坑六，迁移报告里的warning被无视。 前面说过了，再强调一遍，因为我们是真吃了亏的。有个索引没建上，报告里就一条warning，当时没人看。上线两周后，一个查询突然变慢，排查半天发现那个索引压根不存在。你说这找谁说理去。所以规矩就是warning必须逐条看完。
坑七，存储过程的手工修改量。 前面说了七三开，这里补一句。改存储过程的时候，重点盯游标、异常处理、系统包函数这几个地方，这些是语法差异的重灾区。建议让原本写这些过程的人来改，别人接手改，两眼一抹黑，还容易引入新问题。我们后期的做法是把存储过程按原来的作者认领，一人一摊，效率高得多。
坑八，同步期间的隐形大事务。 KFS那节说了，补一句发现办法：你要是看到延迟突然涨，先去源库查当前有没有跑着的大事务，八成就是它。查的SQL网上到处都是，我就不贴了，搜"查会话正在执行的事务"就能找到。
九、要不要自己写脚本，或者用第三方工具
做方案的时候，我们也不是没动过别的念头。这里把当时的对比结论说下，你要是在选型，可以参考。
第一个选项，自己写脚本。用Python或者Java，把数据导出来再灌进去。评估下来，灵活是真灵活，想要啥逻辑都能写。但工作量太大了。类型映射你要自己写全，出错重跑你要自己管断点，数据校验你要自己写比对，大对象你要自己处理，出错之后的人工恢复流程你也得自己设计。我们粗算了一下，要写到能上生产的水平，至少两个人月，而且这玩意写完还得长期维护，谁写的谁背着。算下来不划算。最后的结论是：特殊的、边角的、工具确实覆盖不了的需求，可以写脚本补位；主力迁移靠脚本，不现实。脚本这东西，写着写着就变成一个没人敢动的小系统了，你懂的。
第二个选项，用第三方的ETL工具。我们也试了，通用性是真好，图形化拖拖拽拽就能出活。但两个问题。一个是对金仓的适配深度不够，类型映射、对象迁移这些环节，都有点够不着痛处，很多细节要自己再补一层处理，补着补着工作量又上去了。另一个更关键，做增量同步得解析Oracle的日志，这个能力第三方工具基本没有，或者要额外花不少钱买组件。也就是说，不停机割接这条路，它走不通，或者走得很贵。对我们的项目来说，这条路直接就堵死了，没得选。
所以最后的结论就很清楚了。存量迁移用KDTS，增量同步用KFS，特殊需求用自写脚本补位。金仓原厂的这两个工具，跟自家数据库的适配肯定是最深的，报错提示、类型处理、日志解析，这些环节都对得上话。这一年多用下来，这个搭配没让我们在工具层面掉过链子。要说没毛病也不客观，但大面上，够用，好用。
十、我总结的一套迁移工作流
最后把我这一年的做法，整理成一套流程给你。你可以直接抄，也可以按自己的情况改。这套流程的出发点就一个：业务不能长停机，数据不能丢，出了问题能回头。
第一步，摸底。 把源库的对象数量、数据量、大表清单、存储过程数量和复杂度，全部统计出来。这个统计决定了后面的工作量和方案怎么做。大表要单独标记出来，重点关照。存储过程的复杂度也要看一眼，简单查询型的和带复杂业务逻辑的，后面人工修改的工作量差得远。
第二步，测试环境完整演练。 注意是完整。从装工具、建任务、跑迁移、验数据到模拟割接，全流程走一遍。一遍不够就走两遍。每张表的迁移耗时记下来，演练中发现的坑，全部记进文档。这一步最值钱。我们正式割接能那么顺，就是因为演练的时候把雷全趟完了。正式干活那天，其实所有步骤都是熟的，照着清单打勾就行。
第三步，全量迁移。 挑业务低峰，跑KDTS全量。大表按前面说的拆分区并行。跑完先做一轮对象核对和行数核对，大问题先筛掉。
第四步，增量追平。 上KFS，从全量迁移的时间点开始追。追到延迟稳定在秒级，链路就算稳了。然后保持同步状态跑几天，观察稳定性，也顺便看看延迟告警灵不灵。这几天里，业务该干嘛干嘛，两边数据一直贴着走。
第五步，割接。 凌晨窗口，按清单执行。我们割接清单的核心项是这些：停源库写入，KFS延迟归零，执行序列重置，跑核心表的count和sum校验，改应用连接串，应用冒烟验证，持续观察。每项做完打勾，两个人一起执行，一人操作一人核对，避免手抖。全程控制在半小时以内，留一半时间应付意外。
第六步，兜底。 割接之前，回切预案要准备好。万一新库跑出大问题，怎么切回老库，切回去数据怎么办，这些要提前想好、演练过。真出了事再想，来不及。我们两个库的迁移都是这么走的，一次都没用上回切，但每次都备着。备而不用，是这个预案最好的结局。
十一、总结
其实如果是做数据迁移这个活，工具只是其中一环。你的方案设计、演练充分度、校验严格程度、割接现场的组织，每一样都影响成败。工具帮我把体力活省了，但操心的事一样没少。反过来说，正因为选对了工具，我才有精力把操心的事做扎实。这两者是个配合关系，不是谁替代谁。