干了大半辈子数据库，我最怕听到三个字：要迁移。DBA圈子里流传着一句话：没迁移过数据库的DBA不是完整的DBA，但迁移过的DBA基本都秃了。这不，上周还有个老同事打电话来吐槽，他们公司要把跑了八年的DB2迁到新环境，光评估报告就写了四十多页，结果一执行还是出了岔子。其实DB2迁移真没这么玄乎，今天我就把这些年踩过的坑和攒下的经验一次性倒出来。
先说迁移前最要命的一步：摸清家底。很多人上来就找迁移工具，结果连自己库里有几张分区表、几个大对象都没数。我见过最离谱的项目，迁移到一半发现有个表居然有200多个索引，其中一半还是冗余的。这种表迁过去，重建索引的时间比数据拷贝还长。所以动手之前，先用db2look把DDL全部导出，逐个表检查分区策略、表空间分布、索引设计，该清理的冗余索引提前干掉，该合并的小表空间提前规划。这步省下来的时间，后面全都能找回来。
接着是选迁移方案。市面上常用的无非三种：离线导出导入、在线CDC同步、还有物理文件拷贝。离线方案最稳妥，db2move export加import，适合停机窗口充足的场景。但很多人忽略了一个细节：导出时千万要带上统计信息，不然导入后优化器瞎选执行计划，性能直接崩盘。在线同步适合7x24小时业务，IBM的CDC工具虽然贵但确实稳定，不过配置复杂，光抓取日志的权限就要调半天。物理拷贝最快，但版本必须完全一致，而且跨平台基本没戏。我的建议是：能停机就离线，不能停机就砸钱上CDC，别整那些花里胡哨的野路子。
说个真实的翻车案例。去年有个金融客户，数据量大概4TB，他们选了离线迁移，计划停机6小时。结果呢？导出用了2小时，传输用了1小时，导入的时候炸了——有个表的数据类型在源库是DECIMAL(20,4)，到了目标库自动变成了DECIMAL(20,2)，精度丢了。查了半天发现是db2move的配置文件里有个参数没改，默认截断小数位。这种坑防不胜防，所以迁移前一定要做个全量数据校验，别光看行数对得上就觉得万事大吉。我一般会写个脚本随机抽几百条记录，比对关键字段的哈希值，比数行数靠谱得多。
再聊聊数据校验这个环节。很多人觉得校验就是把源库和目标库的行数对一下，那真是大错特错。数据一致性不只是数量一致，还要检查约束、触发器、存储过程这些对象是否完整迁移。我有次迁移完，业务方反馈某张表的自增ID从1000开始，但源库明明已经跑到5000了。查了半天，发现是导入时序列的缓存值没同步。这种问题用工具根本查不出来，只能靠业务场景去验证。所以迁移完成后，建议让业务团队拿真实交易数据跑一遍核心流程，别只盯着技术指标。
还有个容易被忽略的坑：字符集和排序规则。DB2的字符集一旦定下来，后期想改就是大工程。我见过一个跨国项目，源库用的UTF-8，目标库按DBA的“习惯”设成了ISO8859-1，结果中文全部变成问号。这种低级错误在测试环境根本发现不了，因为测试数据全是英文。所以迁移前一定要确认业务方的数据源，尤其是涉及多语言的系统，字符集必须提前锁定，最好在迁移方案评审时让业务方签字确认。
传输环节也有讲究。很多人直接拿网络共享盘拷贝，遇到大文件传输中断就抓瞎。我推荐用IBM的MQ或者FTP断点续传，实在不行用rsync分批传。另外，压缩传输能省一半时间，但要注意CPU开销，别把源库所在服务器的性能拖垮了。还有个小技巧：如果数据量特别大，可以按表空间分批次导出导入，别一股脑全倒出来。这样就算某一步出错，也只要重跑那一小部分，不用全盘再来。
说说上线切换那天的操作手册。很多团队把切换想得太简单，结果手忙脚乱。我建议至少提前一周做一次完整的切换演练，包括回滚方案。演练时要把所有步骤写成checklist，每一步谁执行、谁确认、超时多久报警，全都要写清楚。切换当天，先停应用，再停源库，然后做一次增量同步，确认无误后切流量到新库。整个过程最好控制在30分钟内，超过这个时间业务方就会暴躁。别忘了准备一个“后悔药”脚本，一旦新库有问题，能快速切回源库。这个脚本平时就要写好，别等到出事了再现场编。
DB2迁移这件事，说到底就是四个字：准备充分。数据备份、对象梳理、方案选型、校验机制、回滚预案，每一步都做到位了，所谓“无缝切换”就是水到渠成的事。别迷信那些花大价钱买的商业工具，也别指望一次就能完美收官。干我们这行的，得有点工匠精神，把每个细节都抠明白。下次你再遇到DB2迁移，深呼吸，按这套流程走，你会发现，其实没那么难。
