KDTS是金仓提供的数据库迁移工具，该工具提供了两种产品形态：BS浏览器版和SHELL命令行版。BS版通过浏览器以可视化界面方式配置任务，配置和使用都很直观，对新手特别友好。很多用户的生产环境不支持或不允许使用图形化界面，SHELL版本可以通过堡垒机或远程终端以命令行的方式访问源和目标主机，适用于金融等安全性要求比较高的用户生产环境，但SHELL版本需要进行较多的配置，对于新手有一定的学习成本。
考虑到笔者也是个KDTS新手，因此本篇文章围绕BS版本来展开。
配置数据源，创建迁移任务
图形界面配置数据源非常简单，在界面相应的位置填写数据源类型、数据库IP地址、端口、名称，数据库连接驱动、登录的用户名和密码等等一系列信息后，即可完成数据源的配置。配置完成后点击“测试”，如果连接成功会弹出“测试连接成功”的提示，如果失败则会显示出错误原因，便于用户进一步分析。
创建迁移任务是向导式的，根据提示依次选择需要迁移的源和目标数据库，
需要迁移的用户和对象，
配置源和目标数据类型的映射，
并且可以对迁移任务的线程池并行度和队列容量进一步配置。
需要提醒读者注意的是，KDTS是一款单向的数据迁移工具，源端不仅支持Oracle、PG、MySQL、SYBASE、DB2等主流商业数据库，还支持达梦、GBASE以及SHENTONG等几种国产数据库作为数据源迁移到Kingbase，而目标端只能支持Kingbase的V9和V8，其他数据库是不支持作为目标端的。
启动数据迁移任务
配置好数据迁移任务后，点击“保存并迁移”后即可开始数据迁移。
在详细的迁移预览页中可以看到迁移成功和失败的对象数量，对于失败的对象，可以通过Error Log来查看具体错误的原因，不过这个错误日志比较原始，就是JDBC操作数据时的报错，对于问题的分析和诊断，需要有一定的基础。
虽然只是个简单的测试任务，不出意外的仍然失败了，任务进度一直停留在73.56%，之后发现是由于目标数据库空间满了，但迁移工具中没有其他更清晰的日志告诉用户问题到底出在哪。
一个多小时之后再来看任务仍然是执行状态，看起来它永远也不会结束，即使我点了“停止”，仍然倔强的执行着。。。
几点建议
说实在的，KDTS 和我所期望的迁移工具还有比较大的差距。在我看来，一款成熟的或者说可用的迁移工具，应该具备以下几点最基本的功能：
迁移过程中出现的错误，要有详细的错误日志记录所发生的问题，让用户能够根据错误日志快速了解和定位真正的问题所在； 迁移工具应该有完善的退出和重试机制，迁移任务出错在所难免，但是要能够及时感知到数据库侧的状态并及时反馈到工具端，并且在错误修复之后要能够重试，避免因为一个细小的错误导致前面所有的工作都前功尽弃； 工具应该具备能成迁移脚本的能力，真实的生产迁移项目是非常复杂的，也会面临很多个性化的需求，比如需要对迁移前后的数据结构做一定的调整，比如迁移过程中会涉及性能的调整。通过工具快速生成出基础的迁移脚本，再对脚本进行个性化和性能(如调整并行)相关的调整，将会大大增强工具的实用性。
写在最后
一直以来，我都认为国产数据库相比于开源产品的优势在于提供了较为完善的外围生态工具，如监控管理、数据迁移等等，这些工具可以大大节省用户的学习和运维成本，从而快速从国外商业产品过渡到国产数据库。
但是仔细评测下来，却有一种“只可远观而不可亵玩”的感觉，看起来各种配套工具一应俱全，但真正使用后才发现远不是那么回事。抛开内核不谈，即使是工具我们和国外成熟商业产品仍然存在不小的差距，需要我们少谈一些空洞无物的概念，少写一些天花乱坠的PPT，用心去挖掘客户的需求，深入到一线去发现用户真实的使用场景，如此才能推动我们技术的真正进步。
