Oracle 18c RAC 集群 RUR 从18.3.0 升级到18.3.1

本文链接：https://www.cndba.cn/dave/article/3142

1. 18c 补丁版本说明

Oracle 从18c 开始，版本号和补丁结构发生了明显的变化，新的补丁体系里只有RU和RUR的概念。版本号也只有前三位有效，如下图：

• 第一位数字是Oracle数据库的主版本号，比如Oracle 18c，12c。 从Oracle 18c开始，第一个数字表示Oracle数据库版本发布的最初的年份，比如2018年是Oracle 18c(18.0.0.0.0)的最初发布年份。
• 第二位数字是Oracle RU（Release Update）的发布季度。比如18.3。
• 第三位数字是Oracle RUR（release updates revision）的发布季度，比如18.1.1，18.2.1，18.3.0。

所以从18c 开始，我们打补丁，实际上打的RU或者RUR。 本文档我们看Oracle 18c中如何打RUR的补丁。 即从18.3.0 升级到18.3.1。 具体的Patch可以从MOS上下载。

RU如下：

RUR如下：

2. 当前RAC集群环境

当前GI和DB的版本都是18.3.0。

3. 开始打RUR

Oracle patch的压缩包里都会有一个readme 文件，可以查看该文件，了解打Patch的步骤。

3.1 RUR Patch 说明

在第一节讲RUR的时候，看到官方分别给出了DB和GI的RUR。 实际上，GI的RUR中，也包含了DB的RUR，所有在下载的时候只需要下载GI的RUR即可。

3.2 检查OPatch工具版本

在Oracle 18c的RUR，OPatch的版本必须大于12.2.0.1.14. 最新版本的Opatch可以从MOS 6880880上下载。 目前最新版是OPatch 12.2.0.1.16 for DB 18.x releases (OCT 2018)。

18c中默认版本就是12.2.0.1.14，所以不用升级Opatch，如果要申请，可以参考我的博客：
Oracle 更新 OPatch 工具版本 的方法 说明
https://www.cndba.cn/cndba/dave/article/1353

3.3 验证Oracle Inventory的有效性

GI HOME 和DB HOME 都需要验证，分别使用grid和oracle用户执行如下命令，确保返回SUCCESS：

3.4 检查Patch 是否冲突

18.3.1的GI RUR里包含5个补丁，所有我们需要执行5次检查：
用grid用户执行以下3条：

用oracle用户执行如下2条：

我这里的执行的命令如下,这里用不同用户执行之前先必须修改patch包的权限，否则会报错：

3.5 检查系统空间

在打Patch之前需要先确保ORACLE_HOME 所在的文件系统有足够的空闲空间，可以执行如下命令来检查。

用GI用户创建临时文件并添加如下内容：

用DB用户创建临时文件并添加以下内容：

3.6 自动应用patch

在DB HOME的版本和GI HOME的版本一致的情况下，可以使用opatchauto对这2个HOME进行Patch操作。该操作必须使用root用户执行，如果GI HOME和DB HOME不在共享存储上，那么必须分别在不同的节点上运行，但不能同时运行，只能一个一个节点来。

根据命令选项的不同，opatchauto调用可以对GI HOME,DB HOME,或者同版本的GI 和DB HOME进行操作。

用root命令执行如下操作，首先设置OPatch的环境变量：

对同版本的GI 和所有DB HOME 进行patch：

对GI HOME 进行patch：

对一个或者多个DB HOME 进行patch：

示例如下：

注意事项：

1. 操作之前，db 和 gi我都没有关闭，是在patch过程自动进行的启停，这里只会停止操作的节点，另外的节点正常运行。

2. 注意patch 的应用顺序，是先应用DB的，再GI.

3. Patch 应用成功，但因为之前测试Flex ASM 之后，导致db1 跑到了节点2运行，所以这里SQL 加载失败，提示让我们手工运行。

   ora.cndba.db 1 ONLINE ONLINE rac2 Open,HOME=/u01/app/o racle/product/18.3.0 /db_1,STABLE 2 ONLINE OFFLINE STABLE

   1 2 3 4 5

   ora.cndba.db 1        ONLINE  ONLINE       rac2                     Open,HOME=/u01/app/o                                                       racle/product/18.3.0                                                       /db_1,STABLE 2        ONLINE  OFFLINE                               STABLE

   因为我们的GI 和 DB HOME 不是共享的，所以讲patch 上传到节点2，然后进行同样的步骤，这里不在重复记录。

但是在第二个节点执行的时候报如下错误：

从日志看已经加载过SQL了，但GIMR没有连接上，导致报错。 这个我们放到下节看。

3.7 加载修改后的SQL到数据库

打补丁后会修改一下SQL，这些SQL还没有加载到数据库中，需要运行Datapatch工具将这些修改后的SQL重新加载到数据库中，如果是RAC环境，只需要在一个节点执行就可以了。

对于18c的CDB架构，执行如下步骤：

1. sqlplus /nolog
2. SQL> Connect / as sysdba
3. SQL> startup
4. SQL> alter pluggable database all open;
5. SQL> quit
6. cd $ORACLE_HOME/OPatch
7. ./datapatch -verbose

datapatch命令只对打开的数据库生效，所有Oracle建议在执行该命令之前将CDB和所有的PDB都打开，一次更新掉。 但如果有部分PDB没有打开，也可以在打开之后，重新运行datapatch命令。

我们从前面patch的日志看，在第二个节点执行的之后，已经执行过脚本。 我们查询视图发现并没有记录，应该是之前失败导致的。

那么我们重做执行脚本：

查看版本：

这次SQL更新注册到了视图。但是之前GIMR的错误还没有处理，我们连接GIMR查看一下：

从查询看，已经升级了。

因为这里加载SQL只对已经open的实例有效，我们这里在操作之前库都已经打开了。如果有未打开的数据库，参考我的博客，单独对这些实例进行操作：
Oracle 18c 单实例 RUR 从18.3.0 升级到18.3.1 操作手册
https://www.cndba.cn/dave/article/3138

3.8 通过OPatch 确认Patch信息

3.9 处理无效对象

最后一步就是处理无效对象，因为之前datapatch命令会加载SQL，这个过程可能会产生无效对象。 可以执行@utlrp.sql脚本处理这些无效对象：

至此Oracle 18c RAC 集群RUR升级完成。

参考

https://www.cndba.cn/dave/article/3142