oracle 数据迁移 怎么保证 和原表的数据顺序一致_如何做好数据迁移？

随着业务发展，系统不断演化，应用职责也会随之发生变化，同时就会伴随着系统数据的改造、迁移、拆分、归档等需求，下面分享一下做数据迁移的一些经验。

第一阶段，做好背景了解统计迁移范围

包括但不限于迁移涉及的表、接口、接口调用上游业务方、如何测试等信息，最好做文档记录输出迁移范围。

第二阶段，分析第一阶段结果确定迁移方案

这里的分析需要注意的重点有两个：

1 接口的迁移：接口的迁移如何保证平滑迁移，也就是上游调用接口切换到新接口的过程中如何保证数据的不丢失，上游是否有重试机制，重试不成功是否有人工补偿机制，上游未切换的机器流量打到老接口插入到老表中的数据如何同步给新表，遇到唯一索引冲突如何解决等。

2 数据的迁移：即将原表的数据迁移至新表中，这里需要分析是单表迁移单表还是单表拆分多表，如何保证数据迁移过程中增量数据的不遗漏，自增id如何不冲突等。

通过分析、讨论、沟通之后可以推演出一些方案，然后对比优缺点和排期等因素确立方案。

比如，保证增量数据不遗漏比较常见和有效的做法是进行数据双写，也就是说原有接口写数据到老表的时候，将同一条数据插入新表中。因为数据从一个应用迁移至另一个应用中也有不同的双写双写方案。

方案1 双数据源双写：在原有系统中配置新表所在数据源，写入老表的时候同时插入完全相同的一条数据(包括自增的id)，这样使得前后数据表现形式一致。

方案2 单数据源写+新接口调用：原系统写入数据之后，调用新接口进行同一条数据写入。

然后对比方案优缺点：

方案1：迁移简单保障排期上线，不需考虑方案2调用接口出现的各种问题，另数据写入qps不高，双数据源数据库存储无写入压力。

方案2：一步到位，将接口功能同时具备并且内部调用验证，但迁移和测试需要时间较多可能数据双写排期逾期。

最终确立按照方案1执行。

第三阶段，老数据迁移至新表

这个阶段需要跟DBA进行沟通，看是否有成熟的同步方案，如果没有DBA也没有成熟方案，那么最基本的做法就是考虑数据迁移过程中，保证应用性能不受数据库锁表等问题的影响。

最后阶段，上游接口迁移

这个阶段属于收尾阶段，但很关键，上游切换过程中未切换的机器还在调用老接口，不过没关系因为数据已经双写会同步写入新表中；切换完成的机器调用新接口，插入数据到新表中，那么问题来了，新表中的自增id从多少开始？如果从1，那么老表id=1的数据如何处理，不能丢掉也不能替换，都是有用的数据啊。简单的办法：在背景调研阶段，估算每天数据插入量，新建表的时候将自增id从一个较大的安全数开始。比如：接口每天产生10000条数据，迁移上线新接口需要10天，目前老表数据id自增到120万，那么估算新建表的数据可以为：10000*10*10=100万，为原来每天增量的10倍，新表自增id从220万开始就可以了。

总之：看似简单的几个接口的迁移，中间需要不断地与有经验的前辈进行沟通、探讨和请教，掌握从DBA、上下游数据补偿逻辑、测试而来的信息，才能完成一个较为保险和行之有效的方案。