Datapump数据迁移的实践总结

虽说实践了不少的数据迁移项目,但是从我的感触来说,一些很细小的差别就会造成整个数据迁移方案的大不同。数据是系统的核心命脉,所以对于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)迁移是一件苦活,需要始终保持注意力,细心的对待可能出现的问题环节,对于突发情况还是要冷静,这个当然多说无益,实践出真知。

相关推荐