8.3 迁移与改造全流程

8.3 迁移与改造全流程

本节摘要：数据库迁移是高风险项目，风险控制靠流程而非勇气。本节给出六阶段迁移法——评估、试点、双轨、校验、割接、回退预案——每个阶段有明确交付物与退出标准，并以一次真实的 Oracle 迁移串起全程。

为什么迁移事故总是相似的

复盘各家迁移事故，剧本惊人一致：评估时乐观报了工期，试点环境没跑真实数据量，割接当晚才发现对象缺漏，回退预案停留在"理论上可以"。这些事故的共性是跳过了流程中的某个"无聊"阶段。迁移的本质是风险管理：数据是企业资产，割接窗口是稀缺资源，任何一步的侥幸都会以停机时间计价。六阶段法就是把每一步的"无聊"制度化。

六阶段：各自的交付物与退出标准

阶段一，评估。交付物是三个数字加一份清单：对象通过率、过程改造人月、隐式行为风险清单（8.1 的算账方法）。退出标准：业务方对改造工作量签字确认，风险清单每条有应对方案。

阶段二，试点。选一套非核心系统（或核心系统的影子库），用真实数据量的拷贝走完整迁移链路：结构转换、数据搬迁、过程部署、应用回归。交付物是试点报告：每个环节的实际耗时——它是割接窗口排期的唯一可信依据。退出标准：试点全流程无阻断问题。

阶段三，双轨。存量系统与目标系统并行运行，数据经增量通道持续同步，应用逐步切读目标库验证功能与性能。双轨期是发现"隐式行为差异"的唯一机会——测试环境永远复现不了生产数据的刁钻边界。退出标准：连续 N 天数据比对零差异、性能达标。

阶段四，校验演练。正式割接前的一次全要素彩排：按割接脚本完整走一遍（含校验与回退演练），计真实耗时。这一阶段专治"脚本在纸上是通的"。

阶段五，割接。按彩排过的脚本执行：停写、追平增量、最终比对、切换连接、冒烟验证、开放流量。每一步有计时与检查人，超时即触发预案。

阶段六，回退预案与观察期。回退预案不是文档摆设，它要回答三个问题：什么条件触发回退（定义在割接前，如冒烟失败或性能低于底线）、回退的执行路径（反向切连接、追回增量）、回退后的复盘安排。割接后设一周观察期，监控按第 7 章三层仪表盘加严。

图：六阶段迁移流水线与关键交付物

完整案例：某保险核心系统 Oracle 迁移实录

背景与起点。保单核心库约四 TB、对象五千余个、存储过程八百个，监管要求年内完成替代。评估阶段（三周）：工具扫描通过率百分之九十一，失败对象定性后折算七人月，隐式行为清单五条（空串处理、日期格式、行号写法、层级查询、锁等待语义）。试点阶段（四周）：选理赔查询子系统真实拷贝迁移，实测结构转换四小时、数据搬迁（限速通道）九小时、过程部署与回归三天——这些数字直接生成了割接窗口的排期依据。

双轨与校验（十周）。增量同步通道上线，应用逐步切读；前两周天天比对出差异，逐条归因：三类是同步配置问题、两类是隐式行为、一类是应用改造遗漏。第六周起连续三十天零差异。校验演练（一周）：全要素彩排两次，第一次暴露了比对工具在四 TB 量级下的内存问题（改为分块校验），第二次全程四小时五十分钟达标。

割接与观察。周末窗口执行：停写后增量追平四十分钟、最终比对二十五分钟、连接切换与冒烟三十分钟，全程比彩排快——彩排的价值再次应验。观察期一周，监控发现两个此前没暴露的问题（一个统计收集时点、一个连接池参数），都在观察期内消化。项目复盘时业务方总结："没有惊险环节"——迁移项目的最高评价，就是所有惊险都留在了演练里。

校验清单：割接当夜的核对表

割接当夜按此表逐项打勾，缺一项不进入下一步：停写生效确认（所有写入入口）、增量位点追平确认、对象计数比对（表数量与各表行数）、抽样内容比对（关键字段抽样核对）、过程与视图部署核对、权限与账号核对、连接切换清单（应用、代理、任务调度逐个）、冒烟用例通过、回退触发条件重申（全员知晓）、观察期值班排班确认。这份清单建议打印成纸质版挂在作战室——电子文档在深夜的作战室里不如一支记号笔可靠。

数据搬迁的三条通道对比

搬迁工具的选择取决于窗口与数据量。通道一，逻辑导出导入：兼容性好、对象级灵活，适合中小数据量与允许较长窗口的场景；四 TB 级别的库用它，窗口要以天计。通道二，物理备份恢复加增量追平：先把基础备份恢复到目标端，再用日志或增量同步追平到割接点，窗口可以压到小时级，是中型迁移的主力通道。通道三，双轨增量同步（8.3 正文的阶段三）：迁移期间两库并行、增量持续流动，割接窗口只切连接，适合停机以分钟计的核心系统，代价是双轨期的运维投入。三条通道可以分段组合：先用物理通道搬存量、再转增量双轨、割接只切流量——保险系统的四 TB 迁移正是这个组合。选通道的决策变量就两个：可接受的停机窗口与团队对通道的运维能力，诚实地评估这两项，通道选择自然浮出。

迁移项目的排期反推法

迁移排期不要正着排（先定上线日期再倒挤各阶段），要反着推：从校验演练的实测耗时出发，加上双轨期最小时长（覆盖至少一个完整业务月周期，月结类系统必须经历一次月结）、加上缓冲窗口（建议为演练耗时的三成），得出割接最早可行日期；再往前加试点与评估的实测时长，得出项目启动的最晚时间点。反推法的价值是把"业务希望什么时候上"与"技术上最早什么时候能上"摆在同一张表上对话——两个日期的差距就是需要管理层拍板的风险接受度。某制造企业的迁移计划里，业务希望的上线日期比技术反推结果早了七周，最终靠削减双轨时长（接受更长的割接停机窗口）达成折中——这类权衡只有反推法才能让它显式化。

现场问答三则

问答一："双轨期间源库还能改表结构吗？"——冻结结构变更是双轨期的铁律，上游加列要在同步组件与目标端同步实施；实在要变更，走"双轨暂停、变更、追平、恢复"的受控流程。问答二："迁移后性能比源库慢，是不是迁移失败？"——先看统计信息与参数基线是否照搬到位，八成的"迁移后变慢"是统计缺失或参数没按新平台重算；真正归因于内核差异的，按 4.2 的计划阅读法定点。问答三："回退预案演练时发现回不去怎么办？"——这就是演练存在的意义，回不去的预案等于没有；常见原因是回退脚本没覆盖某些下游组件，把演练暴露的缺口补完再申请割接窗口。三则问答对应双轨、性能、回退三大迁移争议，项目例会上直接引用。

本节要点回顾

• 六阶段各有退出口：评估签字、试点无阻断、双轨零差异、彩排可执行，不达标不进下一阶段；
• 排期靠实测：割接窗口的每个耗时以试点实测为准；
• 双轨是唯一机会：隐式行为差异只有在真实生产数据下才现形；
• 彩排三次割接一次：脚本纸上通不算通；
• 回退条件事前定义：触发条件在割接前全员签字，当夜不再讨论。

数据搬进了新家，系统进入稳态。最后一节看向更远的地方：这个数据库和它的社区将往哪里走。