社保系统割接——新老系统数据迁移的完整方法论新老系统切换不是写一条insert into ... select from就完了。表结构不同、编码不同、两套系统的数据字典不同、迁移过程中业务还要停掉——这一切都要在一晚上内完成。这篇文章记录了一次真实的生产环境迁移8个阶段的模块化迁移、DBLink跨库抽取、事前事后的对照校验、以及迁移后的补刀处理。文章目录社保系统割接——新老系统数据迁移的完整方法论一、背景两套系统一张时间表二、DBLink——跨库迁移的基础三、迁移前检查——老系统的表哪些有数据四、模块化分阶段迁移——8个阶段的严格顺序五、迁移后的补刀处理——迁移完成只完成了80%六、迁移全流程总结七、这套方法论的关键决策八、结语一、背景两套系统一张时间表老系统是独立部署的新农保居民养老系统跑了很多年。新系统是一体化的社保平台要一次性接管两个老系统的全部数据。割接的核心矛盾迁移过程中业务不能跑——因为两边数据不同步经办人在这边录了数据那边迁过去了但少了这一条。所以必须选一个业务空窗期停掉所有外围服务在几小时内完成全部迁移。迁移执行的完整时间线17:50 屏蔽报盘功能停止银行扣款/发放 17:50 屏蔽两个区的乡镇经办人员账户 17:53 清空新系统表结构导入新表结构 导入配置表数据 18:22 暂停两个区所有经办人员账户 19:30 开始执行8个阶段的迁移脚本 ↓ 一、基础信息模块 ↓ 二、缴费数据迁移 ↓ 三、待遇发放模块 ↓ 四、个人账户信息模块 ↓ 五、财政补贴信息模块 ↓ 六、制度衔接管理 ↓ 七、银行模块 ↓ 八、最后的处理脚本 完成 恢复经办人员账户恢复报盘功能迁移之前先做了两件事屏蔽外围银行扣款接口停掉防止正在扣款的数据在迁移过程中变更屏蔽经办人所有经办账户加tem_前缀暂时冻结防止有人在老系统上操作。二、DBLink——跨库迁移的基础新老系统不在同一台数据库服务器上。老系统在172上新系统在170上。迁移不是导出dmp再导入——是在新系统上建DBLink直接从老系统跨库抽取-- 新农保老系统CREATEDATABASELINK hkxnb_linkCONNECTTOhkxnb_hk IDENTIFIEDBYhkxnb_321USING(DESCRIPTION (ADDRESS_LIST (ADDRESS (PROTOCOL TCP)(HOST 192.168.70.172)(PORT 1521)) ) (CONNECT_DATA (SERVICE_NAME orcl) ) );-- 居民养老老系统CREATEDATABASELINK hnjmyl_linkCONNECTTOhnjmyl_hk IDENTIFIEDBYhnjmyl_321USING(DESCRIPTION (ADDRESS_LIST (ADDRESS (PROTOCOL TCP)(HOST 192.168.70.171)(PORT 1521)) ) (CONNECT_DATA (SERVICE_NAME orcl) ) );两个Link分别指向两套老系统。迁移SQL在目标库新系统上执行数据通过DBLink从源库直接抽取不走导出文件不走网络传输。性能瓶颈在源库的查询和网络带宽不是导出导入的磁盘IO。三、迁移前检查——老系统的表哪些有数据老系统运行了很多年有些表从建表就没有用过。如果不检查一股脑全迁——迁了空表浪费时间还可能因为表名在新系统的字典里不存在而报错。-- 迁移中发现空的表AD59-- 财政补贴划拨到位信息 (空表)-- 该表与AD52(财政补贴划拨到位信息)相同要查证确认AD59是空表而且AD52有同样的数据。所以迁AD52就行AD59跳过。迁移前的空表检查就是一次数据资产盘点——哪些表有数据、哪些是冗余表、哪些可能已经废弃。四、模块化分阶段迁移——8个阶段的严格顺序迁移按业务模块分为8个阶段不是按字母顺序是按数据依赖关系阶段模块迁移表数为什么是这个顺序一基础信息ac01, ac02, ae03, af07, ce01, ac93, ac05, ac24, ac04人员信息是所有后续表的父表必须先迁二缴费数据ab54, ab11, ab10, ac10, ac11, ic50, ad21缴费依赖人员信息三待遇发放ac90, ac63, ac79, ac71, ac61, ac75, ac76, ac77, ac82, ac83, ad34待遇依赖缴费记录四个人账户ac50, ac51, ac53, ac55个人账户依赖参保信息和缴费五财政补贴ad52, ad53补贴依赖缴费和待遇六制度衔接ic03衔接需要基础信息已就位七银行模块dk01, dk02, df01, df03银行代扣代发依赖缴费八收尾处理最后的处理脚本以上全部迁移完成后执行每一阶段只迁该模块的表迁完做一次简单的计数校验新系统的记录数和老系统的记录数是否一致。确认无误后再进入下一阶段。如果有误——停在这里排查不入下一阶段。为什么银行模块没有导入在迁移执行中第七阶段银行模块标注了没有导入。因为银行代扣代发数据涉及外部系统的报文交互报文格式、序列号、时间戳在新老系统之间不完全兼容。这种数据不能直接迁——要在新系统上重新生成。五、迁移后的补刀处理——迁移完成只完成了80%所有数据迁完后还有一批因为数据格式变化、编码标准不同、管辖区划重新划分等原因需要单独处理的数据-- 变更缴费组号-- 补缴缴费组号维护-- 待遇拨付通知维护管辖区编号-- 待遇补发待遇调整-- 征集ID变更管辖区编号-- updateAC82_aaz220_to_AC75.sql这些脚本的共同特点不能批量写进迁移脚本里。因为它们是迁移后才暴露出来的问题——迁之前不知道有多少条受影响迁的过程中发现这类数据异常没法停工去修。所以拆出来作为第八阶段的补刀——全部迁移完成后统一运行这批修复脚本。六、迁移全流程总结准备工作 ├── ① 从源库导出表结构 → 导入目标库 ├── ② 导入配置表数据 ├── ③ 重新编译存储过程和视图 ├── ④ 建立两个DBLink分别指向新农保和居民养老源库 ├── ⑤ 屏蔽银行报盘功能防止外部数据变动 └── ⑥ 冻结经办人员账户防止内部数据变动 迁移执行8个阶段按依赖顺序 ├── 一、基础信息模块 ├── 二、缴费数据 ├── 三、待遇发放 ├── 四、个人账户 ├── 五、财政补贴 ├── 六、制度衔接 ├── 七、银行模块本次未导入 └── 八、收尾处理脚本 迁移后 ├── 恢复经办人账户 ├── 恢复报盘功能 └── 补刀脚本修复迁移中发现的边缘问题七、这套方法论的关键决策1. DBLink直抽不走文件。不导出dmp、不压缩、不传FTP。两套库之间的网络是内网DBLink的吞吐量远高于导出导入。一张百万记录的表insert into target_table select * from source_tabledblink几分钟完成导出再导入要十几分钟。时间窗口就这么几个小时每省一分钟都是在抢。2. 依赖顺序驱动。不是按表名字母序是按这张表的数据被谁依赖谁依赖它就放在前面。基础信息是所有表的父表必须第一个迁。如果反过来——先迁缴费再迁人员信息——外键约束会全部报错。3. 银行模块本次不迁。不是疏忽是外部系统对接数据不适合直接表级迁移。银行代发代扣的报文格式、批次号生成规则、对账序列号——这些都是新系统自己的逻辑。迁了数据但新系统生成的报文格式对不上银行那边解析失败。与其冒险不如在新系统上重建。4. 补刀脚本独立。迁移脚本是标准数据一键迁移补刀脚本是发现一个修一个。不能混在一起——把补刀逻辑写进迁移主脚本里以后排查问题时分不清是迁移的问题还是补刀的问题。八、结语系统割接的数据迁移核心不是SQL写得好不好是流程设计和时间窗口管理。8个阶段的顺序谁先谁后、哪些外围服务必须停、哪些数据不能批量迁要手工修——这些不是在数据库面前想出来的是在割接的计划文档里一条条列出来的。这套方法论从那次割接之后成为了后续所有迁移项目的标准模板——不是因为写得好是因为每个步骤都在生产环境里验证过没出过数据事故。