怎么一步步搞定DB2数据搬迁，别急着跳过关键环节

最重要的一步不是技术操作，而是制定计划，根据IBM官方支持文档中的建议，没有计划的搬迁就像蒙着眼睛开车，非常危险，你需要坐下来，拿张纸或者打开一个文档，明确回答以下几个问题：要搬哪些数据库？是整个实例还是几个重要的表？搬迁的最终目的地是哪里，是另一台服务器还是云端？允许业务停机的时间窗口有多长，是几分钟还是几小时？谁来做这件事，出了问题找谁？把这些问题的答案写清楚,就是你的搬迁路线图。

计划做好后，别急着动手，开始第二步：进行一次完整的备份，这一步是绝对不能跳过的“保险”，IBM知识中心强调，备份是数据安全的最后防线，你必须使用DB2自己的备份命令，对需要搬迁的数据库做一个全量备份，把这个备份文件妥善地保存在一个绝对安全的地方，最好是和当前数据库不在同一台机器上，这样，万一搬迁过程中发生任何不可预料的错误，你还能用这个备份文件把数据原封不动地恢复回来，最多就是损失一点时间,但绝不会丢数据。

第三步是清理和检查，在搬迁之前，给你的数据库来一次“大扫除”，想想看，你搬家的时候肯定也不愿意把没用的垃圾一起打包带走，数据库也一样，检查一下有没有已经失效的临时表、日志文件或者测试数据，把它们清理掉，这不仅能减小搬迁数据包的大小，让搬迁过程更快，还能避免把一些潜在的问题带到新环境里，检查数据库的一致性，确保它当前是健康的,一个病着的数据库不适合长途跋涉。

第四步，选择你的搬迁工具和方法，DB2给了你几条路可以走，你要根据第一步计划里的停机时间要求来选择，如果允许停机时间比较长，比如几个小时甚至更长，最经典、最可靠的方法就是使用DB2的备份恢复功能，你在老服务器上备份数据库，然后把备份文件拷贝到新服务器上，最后在新服务器上执行恢复操作，这个方法虽然需要停机,但非常稳妥。

如果你希望业务中断的时间越短越好，甚至做到几乎不停机，那就要考虑更高级的方法，比如DB2的高可用性灾难恢复功能，这个方法有点像给数据搬家装上了“实时同步”的引擎，它在搬迁开始前就会在新老系统之间建立数据同步，确保两边数据几乎一致，最后切换时只需要中断很短的瞬间，但这个方法设置起来比较复杂,需要你对DB2有更深的理解。

选好方法后，第五步是在一个和生产环境类似的测试环境上进行一次完整的搬迁演练，这一步是很多新手会跳过但老手绝对不敢省的环节，IBM红皮书里多次提到，测试是确保成功的关键，你在测试环境上把整个流程走一遍，从备份、传输到恢复验证，这会帮你发现计划中没考虑到的问题，比如网络防火墙是否畅通、新服务器的磁盘空间够不够、权限配置对不对等等，在测试环境里犯错和解决问题,成本是最低的。

第六步，执行搬迁，到了真正动手的时候了，严格按照你制定并通过测试验证的计划来操作，通知所有用户，在规定的时间点停止使用系统，也就是开始业务停机，执行最后一次增量备份或确认数据同步状态，开始传输数据并使用你选择的方法进行恢复，这个过程中心要细，每一步操作完成后，都要检查一下DB2返回的消息,确认没有报错再继续下一步。

最后一步，第七步，是验证和收尾，数据搬到新家后，千万别急着通知大家系统恢复正常了，你先要自己彻底检查一遍，随机抽查几张重要的业务表，看看记录数对不对，启动几个关键的业务应用程序，试着执行几个典型的查询和操作，看看功能是否正常，确保所有的数据库连接、作业计划都正确地指向了新的服务器，只有当你自己确认一切工作都完美无缺后，才能广而告之，通知用户系统可以重新使用了，搬迁完成后，建议再对新数据库做一次备份,作为在新环境下的一个全新起点。

数据搬迁是个系统工程，耐心和细致比技术本身更重要，跳过的任何一个看似微小的环节,都可能在后头变成一个大麻烦。