设为首页收藏本站

Bo's Oracle Station

【博客文章2016】Oracle12c RAC和Grid Infrastructure部署系列一:使用保障前台业务0暂停的方式升级Oracle11gR2 MAA到Oracle12c MAA

2016-6-17 15:32| 发布者: admin| 查看: 8127| 评论: 0

摘要: 本文介绍:我们已经完成了Oracle MAA 从11.2.0.4滚动升级到12.1.0.2的过程。利用物理Standby->逻辑Standby->物理Standby的转换,整个升级过程中前台业务暂停的时间只有短短的2分钟,几乎可以认定是无影响。

Botang唐波


摘要
 

本文介绍:Oracle12c RACGrid Infrastructure(简称GI)部署系列一:使用保障前台业务0暂停的方式升级Oracle11gR2 MAAOracle12c MAA。原先打算升级一套11.2.0.4MAA系统到12.1.0.2MAA。实验起点为4台主机加2个盘阵组成的MAA架构,4台主机的操作系统都是Oracle Enterprise Linux 6.8 x8664 uek核:

MAA架构中 station9192.168.0.9)和station10192.168.0.10)运行着两节点RAC主库;station11192.168.0.11)和station12192.168.0.12)运行着两节点RAC物理备库。

之后确信独立发现BUG(见:http://www.botangdb.com/forum.php?mod=viewthread&tid=583&extra=page%3D1)。这个BUG本人猜测是由于192.168.0.9192.168.0.10这两个节点ip不对称导致12c软件调用Perl程序去取字符串时少取一位造成的。使用完全“干净”的环境实验,确证过数十次。经过反复折腾,实验环境不得不重新准备。改成仍升级一套11.2.0.4MAA系统到12.1.0.2MAA。实验起点仍为4台主机加2个盘阵组成的MAA架构,4台主机的操作系统仍都是Oracle Enterprise Linux 6.8 x8664 uek核。 但是IP地址做了更换:

MAA架构中 station11192.168.0.11)和station12192.168.0.12)运行两节点RAC主库,station13192.168.0.13)和station14192.168.0.14)运行两节点RAC物理备库。(由于本实验起点是预装好的11.2.0.4MAA,起点很高。准备环境和更换环境都是非常大的工程。真是幸好所有环境都是由PXE推送器推出来的,非常一致和完全“干净”。)

在升级过程中显然应该先升级GI12c。升级12cGI过程中,由于数据库软件仍然是11.2.0.4MAA架构得以继续保持物理Standby架构。但是请注意所谓“保障前台业务0暂停的方式”是这样的:升级GI过程中是通过Dataguard Switchover技术实现Rolling Patch的。在Rolling Patch过程中,我们只能保证主库时刻都在线,而物理备库(至少其中的一个实例)是会在升级GI过程中多次重启的。实际上升级GI和之后所有的升级活动都是先在备库上进行的,然后通过Dataguard Switchover技术把升级好的备库切成主库,再然后在新备库(原主库)上进行第二批升级活动,最后通过Dataguard Switchover技术切回最初的主库备库关系。

GI升级完成后接下来升级数据库软件,这下难题出现了:如果我们先升级物理备库到12.1.0.2,那么备库(12.1.0.2)和主库(11.2.0.4)的版本就会不一样。大家都知道的基本常识是:物理备库和主库数据库软件版本必需完全一样(这两个库的数据文件都是能互替!)。如果数据库软件版本不一样,基于物理StandbyMAA架构就不复存在了,进而就根本不可能Switchover,再进而就完全不可能进行Rolling Patch。但是又要保障前台业务0暂停,所以我们就不能在升级数据库软件过程中破坏的Dataguard架构。大家知道:Oracle只有两种DataguardA. 物理StandbyB. 逻辑Standby。因此经过以上解释,所有人都会自然得出结论:为了保障前台业务0暂停,在升级数据库前,应该先把原先基于物理StandbyMAA架构转成基于逻辑Standby的。

My Oracle Support Bulletin 949322.1就是这么做的。下面介绍过程。


微信查看请扫:

 

目录

1. 环境概览

1.1 升级前环境概览

1.2 备库升级后环境概览

2. 通过两次Dataguard切换,升级所有GI

2.1 主库Dataguard切换

2.2 原主库(新备库)升级后环境概览

2.3 主库Dataguard切换,原主库(新备库)重新成为主库

3. 通过Transient Logical Standby转换,升级所有DB

3.1 My Oracle Support Bulletin 949322.1综述

3.2 升级前的准备工作

3.2.1 停用Datagurad Broker

3.2.2 确保主库和备库闪回区都存在,并都设置了正确的大小

3.2.3 主库和备库配置闪回数据库

3.2.4 确保升级前,备库进行着健康的Recover Managed Standby Database

3.3 第一次执行physru.sh

3.4 Transient Logical Standby上执行dbua

3.5 第二次执行physru.sh

3.6 手工重配置cluster01以便使用12.1.0.2数据库软件直接打开c01orclmount的状态

3.7 最后一次执行physru.sh

3.8 三次成功执行physru.sh后的善后工作

3.8.1 打开c01orcl的所有实例

3.8.2 打开c02orcl的所有实例

3.8.3 验证在dbua过程中做的两个事务在主备库中都存在

3.8.4 重新启用Datagurad Broker

3.8.5 主备库设置compatible参数为12.1.0.2.0

总结

正文

2

鲜花

握手

雷人

路过

鸡蛋

刚表态过的朋友 (2 人)

QQ|手机版|Bo's Oracle Station   

GMT+8, 2018-12-26 06:45 , Processed in 0.109993 second(s), 19 queries .