oracle ojvm组件安装,19c新环境安装补丁(二)

19c新环境安装补丁(二)

之前的上一篇文章中关于19C的补丁安装是在测试环境中，不太顺利！！！

https://www.cnblogs.com/lvcha001/p/12706370.html

本次需求：新上线一套19c数据库，需要安装较新数据库补丁psu!!! 操作系统oracle linux 7.8

一、前期说明：

1.oracle 19c psu ,、RU和RUR的问题

从12.2.0.2开始，Oracle Database开始采用RU(Release Update)和RUR(Release Update Revision)的方式发布补丁。

RU：季度补丁包，包含查询优化器修复、功能修复、安全修复、回退修复。

RUR：季度补丁包的修复，包含安全修复、回退修复。

RU和RUR的切换：可以来回切换，但是新的patch必须是之前patch的超集(新的patch包含了之前patch的所有修复)。

建议阅读MOS文档：Release Update介绍以及FAQ (Doc ID2289879.1)

==

换句话说，12.2.0.2之前，数据库补丁集合只有psu，如果某个psu自身包含某些bug,只能等待后续在出现大的PSU版本进行升级或者某个补丁包实施安装；

但是在12.2.0.2之后，可以在不升级大的PSU版本的情况下，对PSU存在的漏洞进行修复。

例如19.3.0.0

安装19.6.0 版本的psu，与11g类似，某个版本的PSU版本；

安装19.6.1 版本的PSU，及19.6.1是包含了部分修复19.6 psu的漏洞的。 因此，例如19.5.2的版本是修复了2次19.5 版本的psu更稳定！

2. oracle PSU安装选择

1. 新环境，建议使用较新的例如当前最新19.7.0 ,19.6.1,19.5.2 建议使用19.6.1版本psu；2.已有补丁的情况下，需要计算是否兼容，才能确认能否安装该版本PSU

计算方法，举例如下：

最基础的判断原则是新的patch必须是之前patch的超集(新的patch包含了之前patch的所有修复)。另外可以依据以下的简化规则判断。

现有的版本是19.A.B,想应用的版本是19.C.D

如果C+D≥A+B，并且C≥A，可以从19.A.B切换到19.C.D

否则不可以切换3.如果现阶段已经是19.4，想应用补丁，是应该应用19.6，还是19.4.2，这两种应用补丁有什么区别？

在19.4.0上应用19.6.0和19.4.2都可以。Oracle推荐应用最新的Updates，这样可以避免很多已知的问题。但是如果认为使用19.4.0已经达到稳定状态，

希望优先考虑安全更新而不是功能修复，那么可以选择19.4.2，但是有可能会碰到已在最新Update中包含的已知问题。4. 19.4.2是基于19.4.0补丁包的修复，只会包含19.4.0以后的安全补丁，以及对19.4.0中的功能修复的回退修复。

而19.6.0与19.4.2相比，会有更多的功能修复内容。5.假如目前是19.4.2这个RUR版本，是否可以升级19.5.0/19.5.1/19.6.0？

不可以从19.4.2->19.5.0，19.5.0中不包含19.4.2新增的安全修复和回退修复。

可以从19.4.2->19.5.1，19.5.1中已经包含了19.4.2所有新增的安全修复和回退修复。

可以从19.4.2->19.6.0，19.6.0中已经包含了19.4.2所有新增的安全修复和回退修复。6.从 Update 转换向相同季度发布的 Revision 会怎样？比如，从 18.5.0到18.4.1? 虽然后两位的数的和都是5，但是从 high-priority non-security fixes

的角度来看，却是倒退了一个季度？

不可以从Update 转换成相同季度发布的 Revision，例如从18.5.0到18.4.1是不可以的。

虽然它们都是相同季度发布，但是在18.4.1中不包含18.5.0中的功能修复内容，也就是说18.4.1不是18.5.0的超集。7.RUR是在RU的基础上再次修复，还是这2个是独立的？

RUR是在上一个季度的RU基础上进行修复。例如19.4.1是在19.4.0基础上进行修复，而19.4.2是在19.4.1基础上进行修复。8.新发布的RU 是否包含了上一版本的RUR?谢谢

新发布的RU中会包含上一版本的RUR。例如19.6.0中会包含19.5.1和19.4.2中的安全修复和回退修复。9.为什么到19以后第二位表示补丁版本了，而11g的补丁版本不是11.1.0.4.xxx吗？

Oracle从18c开始采用年度数据库软件发布的技术支持策略，并开始使用新的数据库软件版本编号系统。新的版本编号系统会使用3个数字编码格式：年.更新.发布

(Year.Update.Revision)。

软件是哪年发布的 (第一个部分)

哪个季节发布的Update (第二个部分)

哪个季节发布的Revision (第三个部分)10.升级到19.5还是19.6更好？

Oracle推荐保持应用最新的Updates，这样可以避免很多已知的问题。并且可以避免申请很多小补丁，并显著降低更多的补丁维护的操作。

如果已达到稳定状态，并希望优先考虑安全更新而不是功能修复。在这种情况下，可以选择应用 Revisions，但是有可能会碰到已在最新Update中包含的已知问题11 JVM?OJVM PSU主要是针对oracle java VM。从2014年10月开始Oracle JavaVM组件作为一个单独的部分来进行安装。之前是包含在oracle rdbms psu中。

只要oracle db中安装jvm组件，就需要安装对应版本的oracle JavaVM PSU。如果只是打了rdbms的PSU，安全漏洞检查就会检查出jvm的安全漏洞。"Oracle JavaVM Component Database PSU" (OJVM PSU) Patches (文档 ID 1929745.1)

如果漏洞扫描，或者有需要对这个组件安装补丁，除了PSU之外，还需要单独安装改JVM补丁包。

二 、补丁实施

1.GI,Oracle软件安装，DB均已安装完毕；2.OPatch工具已更新至满足PSU安装需求；3.正式打补丁操作！节点1 正常安装成功。

节点二安装失败。

[root@d1~]# /u01/app/19.0.0/grid/OPatch/opatchauto apply /xx/psu_soft

[root@d2~]# /u01/app/19.0.0/grid/OPatch/opatchauto apply /xx/psu_soft

报错1.java.io.FileNotFoundException: /u01/app/oraInventory/ContentsXML/oui-patch.xml (Permission denied)

参考

http://www.360doc.com/content/20/0701/11/70704971_921618143.shtml

权限不对，节点1正常，节点2 报错，将节点1的属组，同步至节点2，chmod777文件！

报错1发生时，节点2 CRS已经关闭，无法启动。

修改权限操作后，再次执行补丁安装，无法正常执行！

报错2.CRS-6706: Oracle Clusterware Release patch level (‘nnn’) does not match Software patch level (‘mmm’)

由于之前遇到报错1，修改权限后，希望尝试重新打补丁，但是还是无法执行，计划启动CRS，结果CRS无法启动！！！

参考

https://blog.csdn.net/xxzhaobb/article/details/105863140

--参考MOS文档处理

CRS-6706: Oracle Clusterware Release patch level ('nnn') does not match Software patch level ('mmm') (文档 ID 1639285.1)

Patching12.2.0.1 Grid Infrastructure gives error CRS-6706: Oracle Clusterware Release Patch Level ('748994161')

Does Not Match Software Patch Level (文档 ID 2348013.1) --实际参考这个文档

[root@node19c02 bin]# ./clscfg -localpatch

[root@node19c02 bin]# ./rootcrs.sh -lock[root@node19c02 bin]# ./crsctl start crs

启动CRS后，回退ORACLE_HOME,GI_HOME的补丁。

[root@d1 ~]# /u01/app/19.0.0/grid/OPatch/opatchauto rollback /xx/psu_soft -oh $GRID_HOME

[root@d1~]# /u01/app/oracle/db_1/OPatch/opatchauto rollback /xx/psu_soft -oh $ORACLE_HOME

报错3.ORACLE_HOME/inventory/oneoffs/29834717 is corrupted. java.lang.RuntimeException: No Patch exists,Please check.

回退所有补丁后，再次尝试在节点2安装补丁，报如下错误！

Patch: /soft/29708769/29834717Log:

Reason: Failed during listinginAnalysis: java.lang.Exception: oracle.opatch.opatchsdk.OPatchException: Unable to create patchObject

Possible causes are:

ORACLE_HOME/inventory/oneoffs/29834717 iscorrupted. java.lang.RuntimeException: No Patch exists,Please check.

After fixing the cause of failure Run opatchauto resume

]

OPATCHAUTO-68061: The orchestration engine failed.

OPATCHAUTO-68061: The orchestration engine failed with return code 1OPATCHAUTO-68061: Check the log formore details.

OPatchAuto failed.

参考

https://blog.csdn.net/qq_16729455/article/details/100531020

报错提示的目录在节点2不存在，但是在节点1存在，在节点1正常psu安装后的相同位置，使用grid用户，将整个目录cp过来即可。

[oracle@node1 oneoffs]$ scp * node2:$ORACLE_HOME/inventory/oneoffs/

再次安装psu 完美，搞定收工。