Datapump数据迁移的实践总结 (r9笔记第60天)

虽说实践了不少的数据迁移项目，但是从我的感触来说，一些很细小的差别就会造成整个数据迁移方案的大不同。数据是系统的核心命脉，所以对于DBA来说，保证数据的一致性和准确性是一个最基本的要求。对此我的一个基本观点就是高可用的需求除非特殊需要，一般都还是需要一个维护窗口的，这种方式更为保守，但是更为保证。 而在Datapump迁移中还是遇到了不少的小问题，也算是一些心得或者建议吧。 1）如果是跨平台的数据迁移，在升级前需要得到一个清单，包含哪些失效的对象，是否需要重新编译，如果不确认，在迁移之后就会更加迷茫，到底是不是迁移之后造成的问题。 2）数据迁移中还是建议直接停掉监听，保证没有其它的外来连接，在之前的大型数据迁移中，虽然从口头上制度上会有一些约束，但是不能完全保证其他人能够完全遵守，有时候应用的同事需要提前检查一些数据，可能会想做一些查询，这个就比较难控制了。而且很可能会触发一些小问题，尤其是性能问题。 3）如果在数据迁移时条件允许，还是建议直接设置为非归档模式，有缺点也有优点，优点是整体的速度会提高差不多1倍，但是缺点是主备库的架构会需要重建，而且在数据迁移后期，收集统计信息的阶段其实会消耗掉不少的时间，如果是非归档模式，必须要等待迁移彻底完成才可以，而如果时间窗口允许，而且需要保证主备库的架构，只能在归档模式下，优点就是保留了主备的架构，无需重新搭建，另外一个有点就是编译存储过程，收集统计信息的阶段，其实已经可以在内部开始一些基本的验证和测试了。因为内部的一些流程和步骤本身需要一些时间，所以这个时间段就可以充分结合起来。缺点也很明显，效率上会差一些，而且需要额外的空间，同步增量的数据需要较高的带宽。所以这是一把双刃剑。 4）在源库中导出dump，传输到目标库的时候，不要开启过多的传输进程，这个时候会有一种问题就是会严重影响其他的客户端连接进来，这里也有一些需要注意的地方，有时候还是很值得琢磨琢磨，比如有1000个dump，那么我们肯定不可能开启1000个进程同时传输，我们只能开启一小部分，始终保留有数据的传输，这个持续的过程就有几种考量，一种是一批一批，比如一次30个dump，完成之后再开启30个dump的传输。另外一种是按照时间的先后开启30个，但是始终保证后台运行偶30个dump的传输进程。第一种方式可以做成脚本的模式，但是可控性，灵活性略微差一些，而第二种就是半自动的方式，需要很多时候人工介入。 5）在传输dump的时候还是直接使用固定的IP而非绑定的漂移IP，这个性能差异个人感觉还是非常大的，在演练中使用同样的硬件环境，同样数据量大概需要传输40分钟，而使用绑定IP,漂移IP这个性能就差了很多，花费的时间多了一倍。 6）如果在迁移后目标服务器的IP需要变更为源服务器的IP，这这个过程中让人比较纠结的就是DB Link,而随着相关的就是含有DB Link的存储过程，包体，视图等。这个过程尤其需要注意，建议还是在迁移前就修改IP，保证防火墙信息和源库一致，这样DB Link的坑就会避免。迁移升级的时间，每一分钟都是需要尽量去争取的，对于系统级的网络超时是一分钟，如果存在大量的存储过程存在过多依赖，那这个编过程就会大打折扣。 比如我们在迁移中碰到的存储过程编译。 ALTER PROCEDURE "TEST"."P_TEST" COMPILE PLSQL_OPTIMIZE_LEVEL= 0 PLSQL_CODE_TYPE= INTERPRETED PLSQL_DEBUG= TRUPLSCOPE_SETTI NGS= '' REUSE SETTINGS TIMESTAMP '2014-09-18 07:35:33' 其实这种编译过程能花费什么时间，时间都在网络的验证超时上了。 7）迁移的演练非常重要，尽可能完全仿真整个迁移的过程，如果嫌麻烦跳过了一些步骤，或者认为可能影响不大忽略了一些小的步骤，那么这些问题就会交给迁移时间，碰到了问题处理起来就非常痛苦了。 8）迁移前的准备越充分，迁移的时候就会越轻松，迁移最后有一个检查清单和步骤，特别是在有时候工作不在状态的时候，这个就是一个纲要和指导方针。 9）迁移是一件苦活，需要始终保持注意力，细心的对待可能出现的问题环节，对于突发情况还是要冷静，这个当然多说无益，实践出真知。