数据迁移笔记

最近接到任务做系统改造升级，其中一项主要工作是数据库的迁移。

旧系统没有测试环境，每天产生的数据约30万，数据总量约1.5个亿，130多张表，30多个存储过程，数据库为SQL Server 2000，没有设计文档。

新系统使用 Oracle 11g，结构与旧系统基本不同。

新系统上线同时旧系统下线，所以要求数据在系统切换前全部导入，客户一如既往的着急。

操作步骤：

1. 首先备份生产环境数据库，并在开发环境还原

2. 统计旧系统数据库每张表的行数，先把没有数据的表删除

3. 发现数据库小于100的表基本都未配置表，这类表没必要迁移，了解业务规则对应关系后可直接在新系统创建

4. 对剩下的表按名称排序，从中大概可看出各模块的划分，删除中间表和临时表。至此，对旧库的整理告一段落，开始研究新系统

5. 分析新系统，看看新系统如果正常运行数据应该是什么样，再看旧系统是否能提供相应数据，对数据对应关系做图

6. 用 Java 写了迁移程序，开始向测试环境迁移，但是效果不理想，因为表结构不同，查询比较繁琐，且插入的速度很慢，计算了一下，全部迁移完需要跑几个星期，很失落

7. 开始从代码上优化，首先考虑了批量执行，速度明显提高，但是仍不够理想，因为插入的是同一张表，无法多任务同时跑

8. 放弃了 Java 直接导入的方式，改成 Java 生成 Oracle 的脚本，再使用 SQLPLUS 的命令导入，速度再次提升

9. 很无奈，新系统有大量的自增主键和外键关联，直接导入数据无法通过验证。所以调整策略，在SQL Server创建了和Oracle 一样的表结构，通过各种 Select 和 Insert 将旧系统数据导入新建的表，导入的过程中创建主键，对于超多数据量的表，可以在此过程中直接分组，全部导入后再通过 Update 更新关联外键。至此，数据库从异源异构变成了异源同构

10. 接下来迁移工作就顺畅多了，还是用 Java 生成导入脚本，再生成批处理文件，在目标库直接还原，不用担心约束和网络中断的问题了

11. 但是超过1亿条的数据导入仍需很长时间，为了保证切换时的顺畅，将数据按时间点切分，已稳定的数据预先导入新库，其余数据增量插入。

最终算是蒙混过关了，没做过类似的迁移工作，没想到会遇到这么多坑。两周后会有个大10倍的库做迁移，希望顺利！

转载于:https://my.oschina.net/tonglei0429/blog/500083