ITPub博客

首页 > 数据库 > Oracle > 迁移式升级的一点思考

迁移式升级的一点思考

原创 Oracle 作者:jeanron100 时间:2016-09-19 23:13:16 0 删除 编辑
目前有一个很实际的需求,因为硬件老化严重,需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上,避免潜在的硬件故障导致的业务停顿,也算防患于未然吧。
本来这个事情不是很紧急,但是因为硬件故障导致的问题防不胜防,踩过几次坑,就会有些经验教训,在这种情况下维持现状就是一个潜在的炸弹。
当前的硬件环境是Solaris,Oracle 10gR2 单实例,数据量在800G左右。我大体想了下,主要的目标有以下几个。
    1.借助这次维护的时机,能够把数据库升级至11g
    2.升级的过程需要尽可能保留一个较短的时间窗口,计划在2个小时以内完成
    3.有较好的解决方案去演练整个过程,多次总结,提高迁移的效率,保证质量
    4.有完善的回退计划,能够支持回退场景下业务平滑过渡
    5.目前对于跨平台没有明确的要求,可以继续使用Solaris,也可以考虑跨平台,但是影响范围要小。
大体就是如上的要求,这是我的想法,也得我自己想办法来落实这些问题:)
有以下几种方式可以做,不过都是在评估和考虑。
    exp的方案肯定是pass,这个数据量迁移2个小时是完全不可能。
    expdp的方案2个小时也是无法达到,有两个瓶颈,一个是CPU使用的瓶颈,导出dump,导入dump得依赖于系统资源,二是主库还得备有额外的空间,三是网络的瓶颈,传输dump这个地方无法控制,而且因为硬件老化,网卡在大批量并发的情况下出现故障那就悲剧了。
    OGG的方案可行性高,之前和几个兄弟讨论过,先在备库的基础上基于SCN做全量同步,再设定数据同步的频率从主库同步,这样第一次的初始化对于主库的压力大大降低。不过有个问题是服务器实在是年岁已高,不能完全保证在主库,备库折腾一番,服务器还依旧吃得消。当然这个也是借口啦,OGG也得花一些时间才能玩得转。高效,可控的基础是熟练掌握它。
    使用XTTS的方案也不错,技术实现上肯定是妥妥的。这种方案的一个瓶颈还是在于网络的带宽,而且XTTS的方案实现在10g版本上还没有亲自尝试过,如果试水,还是有一些风险。
    使用DBUA的方式来升级,也是一个不错的方案,先使用Data Guard切换,然后直接升级至11g,图形的方式或者是命令行的方式均可。这种方式的优点很明显,升级前的检查和准备足够充分,升级数据库的时候就会平滑许多,自己也这么参与过不少的案例。这种方案和数据量就没有太大的关系了,升级的本质就是升级数据字典,所以这部分的时间主要就花费在升级上。
    还有一种方案自己也在琢磨中,那就是Data Guard+TTS,实现的思路大体是备库上创建一个11g同名的数据库,然后原来10g的数据库Failover变为主库,导出元数据,然后修改11g数据库的配置,导入元数据,这个过程中出了系统表空间外,数据表空间不动。这样就可以直接避免文件迁移带来的很毒瓶颈和限制。
    这几种方案个人比较喜欢最后一种,先说维护窗口,如果免去了拷贝数据文件的时长,那么导出导入的过程就会很快,应该比手工/图形方式升级数据库还要快。如果保证能够反复演练,可以合理利用备库的闪回功能,failover之后闪回照样能够修改为物理备库正常应用日志,为了方便演练,可以拷贝一份数据的镜像,随时启用,这样10g,11g的库都可以正常运行。一旦出现灾难,直接把连接切到原来的主库端去即可。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2125173/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14267960