认真就输

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

今天我们来聊聊Oracle集群环境中GRID/CRS大版本升级。别担心，这不是官方文档的枯燥翻译，也不是厂商PPT的自嗨推销，而是一个虚构的案例，案例如有雷同，纯属巧合，请勿对号入座。

环境介绍

先来介绍下主角：客户有好几套AIX平台的RAC要升级，配置都差不多。我们挑一套来说：3节点AIX RAC，连着2台做镜像的存储。第三个节点平时像个“摸鱼王”，主机开着，集群和数据库都关着。备库是单机ADG，数据库和集群都是12C，目标是升级到19C。服务器和存储还跨机房、跨网段，妥妥的“异地恋”。这可是客户的核心系统，停机时间卡得死死的——总共6小时，留给我们数据库升级的时间只有3~4小时，压力山大！

升级方案

升级方案的思考

平台的差异性

平台为AIX平台，AIX下有一个致命的问题就是Oracle软件编译的速度非常慢，有多慢呢，时间也太久了，记不住了，基本上GRID和DB编译都需要半个小时的时间，所以无法在升级当天进行软件的安装，这个缺陷是所有想在AIX平台下升级时，必须考虑的一个点。有缺点的同时也有优点，AIX下面的优点是什么呢？那就是在操作系统上迭代时回退方案非常简单，rootvg的镜像功能就可以发挥用处了。

时间的考量

给到数据库的时间在3~4个小时，低于4小时都可以采用二分法，那就是升级和回退各占一半的时间。为什么回退占一半的时间呢？其实数据库升级这种操作回退方案的重要性远比升级方案还重要。所以这里给数据库升级时间只留下了2个小时的时间，2个小时中数据库升级需要消耗30分钟的时间，所以给GRID预留的时间在90分钟。90分钟对于AIX平台下3节点的GRID升级时间确实有点紧张了。

硬件环境

案例中的服务器采用了LPAR（逻辑分区）功能，物理服务器上还有部分资源，可以新建2个分区出来用于搭建一套集群，同时存储空间也够，这样测试环境就有了，同时也会将这个环境利用到极限，来提升数据库升级的效率，后续我们会讲到。

升级方案的目标

是客户最核心系统的升级，需要保证整个升级在2个小时完成，包含主库和备库环境。升级过程中每一步操作都需要有回退方案，并且回退方案要简单，切可以确保能回退，升级后要保证系统的运行的稳定和性能。

技术的引入

VG镜像技术的引入

采用AIX操作系统镜像的技术主要有2个作用，1，通过操作系统镜像技术，搭建测试环境操作系统，可以尽最大能力模拟原生产环境。2，通过操作系统镜像技术，可以用于升级生产环境GRID中或者升级成功后的回退。上面技术由主机工程师来完成。

数据库闪回技术

在升级过程中对数据库开启闪回功能，可以确保数据库升级过程中或者升级成功后的回退。另外使用此技术重构ADG环境和闪回备库功能用于数据库的性能测试、功能测试、稳定性测试和高负载下的系统健壮性。

数据库ADG

利用ADG技术来搭建测试环境和正在割接中利用ADG前滚来升级生产数据库，可节约生产数据库升级的时间，同时也可以做到主库GRID升级和备库数据库升级的同步操作，节约大量的时间。

手动卸载GRID

12C的集群升级到19C的集群有三种方式：
第一种方式是直接升级方式，也就是跑升级脚本，但是这个方案有一定的分享，很有可能升级过程中出现什么幺蛾子，生产环境中无法一对一模拟，所以有一点的风险，另外耗时久，同时升级过程中会更新OCR磁盘组的信息，导致回退技术被限制。
第二种方式是直接卸载12C集群，添加节点19C集群中，也就是从rootcrs.pl -deconfig这个方式，这个方式相比上一种来说，风险要低一些，不涉到集群配置信息的修改，但是这种方式仍然会删除一些OCR中的资源，这些资源虽然可以通过后续的手动添加或者跑root.sh的方式来恢复，但是相比来说回退的技术收到限制切回退有风险。
第三种方式手动卸载12集群，添加节点到19C集群中，也就是手动的卸载tfa和操作系统文件手动的删除，如将/etc/init.d/与/etc/inittab等文件手动的修改，这个方式耗时最少，只需要停集群，删除文件的操作，这次操作都可以提前做成脚本。此技术只动了操作系统文件，OCR磁盘组任何东西都没有动，还原时我们可通过文件手动还原，也可以利用操作系统VG镜像的方式来还原，可完全保证回退方案的有效性。

集群节点添加技术

升级方案

新备库环境搭建

利用操作系统的克隆技术搭建新备库环境的操作系统，在新备库中配置12C集群和数据库环境。

新备库升级到19C测试

1，新备库中新划3个OCR磁盘用于19C的集群，配置磁盘多路径和权限。
2，节点2上编写19C GRID软件和DB软件，并应用RU和oneoff补丁的，并对软件进行打包。
3，关闭节点2的GRID和DB。
4，VG镜像在线分离。
5，手动运行deconfig TFA。
6，备份12C修改的操作系统文件后删除对应的12C的文件，这里需要注意/etc/inittab文件不能删除，删除里面的条目就可以了。
7，配置单节点19C的集群.
8，配置集群过程中将19C打包的软件同步到节点1.
9，集群配置成功，在节点1上面重复上面5、6的操作。
10，采用noCopy方式添加节点。
11，集群软件升级成功。

上述方案需要多做几次，确保每一步都已经脚本化，每一步需要耗时多久，可能出现的故障点和解决方案是什么。

19C回退12C测试

1，关闭集群所有节点的操作系统。
2，利用VG镜像剥离出来的磁盘重启操作系统。
3，确认集群是否恢复。
4，重做VG镜像。

新备库环境的数据库升级

新备库环境利用数据库升级技术来升级数据库即可，这里非常简单，略过。

新备库环境的各种压测

在新备库环境中进行各种压测，能做的所有功能都可以在这里去做。

正式升级操作

前序操作

1，生产环境分配3个OCR磁盘，隐射给第三个节点。
2，生产环境第三个节点删除12C集群，安装19C集群。

割接当晚

1，停业务，停数据库监听（保留ADG同步监听）
2，生产主库启动闪回模式，确保测试环境ADG也启动了闪回模式。
3，停生产环境ADG备库和监听，将监听文件改名，防止后续误操作。
4，主备切换，将测试环境切换到主库。
5，断开所有主从之间的同步，关闭除当前主库以后的所有备库。
下面操作并行进行
6，一个人在主库上面升级数据库。
7，存储工程师映射OCR磁盘到生产环境1、2两个节点
8，主机工程师剥离VG镜像
9，DBA一个人在原生产环境删除12C集群、添加集群节点。
后下串行执行：
8，主库升级成功，进行简单的业务测试和功能测试，确认是否有问题。
9，原主库环境在19C环境中启动12C数据库到mount，开启数据库前滚。
10，前滚结束，进行主从切换，将原生产环境切换为主库。
11，进行业务功能的详细测试。
12，测试完全没有问题后进行下面操作。
13，将测试环境数据库闪回到12C环境，保证升级前的数据库一致性。
14，将生产环境备库切换到19C环境。
15，调整备份、监控等其它内容。

方案总结

以上就是本次“升级大作战”的全部流程。看起来简单，其实每一步都暗藏玄机。做Oracle DBA，光懂数据库可不够，操作系统、存储、网络都得会点皮毛，最好还是资深。本文仅供参考，别直接照搬，毕竟每家环境都不一样。欢迎大家留言拍砖，互相学习！

——————作者介绍———————–
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)