Oracle数据库管理每周一例-第十三期 DBRU中的新变化

第十三期 DBRU中的新变化

本周除了一体机打了个新补丁、调了下参数，星期六又去城市另一端装数据库（这次终于搞完了），感觉比前两周好些。和上周一样，第二周写的本期。
前一周周对两套4节点ADG主备RAC进行了12.2三季度DBRU补丁升级中发现了一些变化，本期对其进行总结。

1.对应版本

本期主要是针对12cR2，以2020年一季度补丁（12.2.0.1.200114）与三季度补丁（12.2.0.1.200714 - 31305382）两个DBRU作为对比。分别从补丁内容、执行时间、执行内容等几个维度进行总结。

2.补丁内容

三季度DBRU补丁（31305382）内容和以前几乎没有什么区别：
Database Jul 2020 Release Update 12.2.0.1.200714（Only DB home for non-Oracle RAC setup. Both DB homes and Grid home for Oracle RAC setup）
OCW Jul 2020 Release Update 12.2.0.1.200714（Both DB homes and Grid home）
ACFS Jul 2020 Release Update 12.2.0.1.200714Footnote 2（Only Grid home）
DBWLM Release Update 12.2.0.1.170913Footnote 2（Only Grid home）
Tomcat Release Update 12.2.0.1.0Footnote 2（Only Grid home）

3.执行时间

使用opatchauto分别对每个节点进行rolling patch，相较于一季度补丁主备每个节点大约15分钟，现在备库节点大约要30分钟左右，主库节点大约需要35-40分钟的样子。经过观察其中GI和DB的软件升级时间有少许增加，但是对数据库的sql patch时间有较大增加。当前补丁执行时间的延长，对于以后申请割接时长、回退时间等，需要注意进行调整。

4.执行内容

从上一节的执行时间来看时间来看，综合后续对GI、DB和数据库的检查，发现以下一些变化：
1.ADG备库opatchauto可以一次性给GI和DB应用补丁了，不需要再手动在DB应用补丁了
2.以前GI和DB升级完成之后，数据库本身的版本不会有变化，这次打完DBRU后，发现数据库版本从12.2.0.1.181016升级到了12.2.0.1.200714，这一点应该是opatchauto执行时间变长的重要原因

5.升级19.8遇到的一些小问题

星期六给新装的4节点RAC，并升级到19.8（三季度DBRU200714），中间遇到了一些问题，下面是问题情况介绍及解决方案：
1.ORACLE_HOME/invenroty/oneoffs/31335188 is corrupted.这个问题在GI和DB中都出现过，在ORACLE_HOME/invenroty/oneoffs/没有生产对应的目录及文件。解决方法可以从成功应用补丁节点的GI或DB对应目录中将这个文件夹复制过去。也可以创建ORACLE_HOME/invenroty/oneoffs/31335188目录后，将补丁patch_unzip_dir/31326369/31335188目录中的etc目录复制到新建目录中并修改权限。后续可使用opatchauto resume/apply成功安装补丁。
2./u01/app/oraInventory/ContentXML/oui-patch.xml(Permission denied)。这个问题通过对正常节点进行检查得到这个文件权限应该是660，但是opatchauto出现异常后该文件权限变成了540。chmod 660 /u01/app/oraInventory/ContentXML/oui-patch.xml之后可以正常执行opatchauto apply。

下期预告：

19c需要调整的参数