前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >迁移式升级的一点思考 (r10笔记第27天)

迁移式升级的一点思考 (r10笔记第27天)

作者头像
jeanron100
发布2018-03-19 17:48:16
5360
发布2018-03-19 17:48:16
举报
文章被收录于专栏:杨建荣的学习笔记

目前有一个很实际的需求,因为硬件老化严重,需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上,避免潜在的硬件故障导致的业务停顿,也算防患于未然吧。 本来这个事情不是很紧急,但是因为硬件故障导致的问题防不胜防,踩过几次坑,就会有些经验教训,在这种情况下维持现状就是一个潜在的炸弹。 当前的硬件环境是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的库都可以正常运行。一旦出现灾难,直接把连接切到原来的主库端去即可。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-09-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档