之前的上一篇文章中关于19C的补丁安装是在测试环境中，不太顺利！！！
https://www.cnblogs.com/lvcha001/p/12706370.html
本次需求：新上线一套19c数据库，需要安装较新数据库补丁psu!!! 操作系统oracle linux 7.8
总结：19c psu 建议安装步骤：
节点1安装GI补丁
# /u01/app/19.0.0/grid/OPatch/opatchauto rollback /xx/psu_soft -oh $GRID_HOME
检查如下文件权限
/u01/app/oraInventory/ContentsXML/oui-patch.xml
节点1安装Oracle 软件补丁
# /u01/app/oracle/db_1/OPatch/opatchauto rollback /xx/psu_soft -oh $ORACLE_HOME
节点2同样重复上述操作；
最后选择任一节点，打开所有PDB，执行db 补丁安装流程。
一、前期说明：
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 ID 2289879.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，chmod 777 文件！ 报错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) Patching 12.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 --实际操作发现grid_home/bin没有此文件，find / -name 查找到的路径操作。 [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/29834717 Log: Reason: Failed during listing in Analysis: java.lang.Exception: oracle.opatch.opatchsdk.OPatchException: Unable to create patchObject Possible causes are: ORACLE_HOME/inventory/oneoffs/29834717 is corrupted. 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 1 OPATCHAUTO-68061: Check the log for more 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 完美，搞定收工。
第二套19C 数据库再次打补丁，参照上一次的补丁问题，提前对权限进行修改。
1.只在节点1,对如下文件chmod 777 节点2不存在该文件。 以及检查oracle,grid oracle_home环境变量，及权限，存在问题尽早修改调整。
/u01/app/oraInventory/ContentsXML/oui-patch.xml
2.打补丁报错
节点1，执行补丁报错
remote command execution failed dut to warning :xxx
can't perl script xxx (null)
原因是节点2的 grid 用户 Opatch目录被我mv 移动，导致opatch null。 但是奇怪在于，我只打节点1的补丁，和节点2的opatch软件有什么关系？？？
因此建议打补丁前，对oralce ,grid的OPATCH均升级至满足psu安装最低需求。
节点1安装补丁正常；
节点2 安装补丁，报错
/u01/app/oraInventory/ContentsXML/oui-patch.xml权限不足？？？
检查发现，节点2 安装，Oracle 补丁后，会自动对上诉文件权限进行修改，调整后的权限是 rw-r--- oracle:oinstall 因此grid没有写的权限。
回退oracle ,grid 补丁。回滚
#oracle_home/OPatch/opatchauto rollback /u01/soft/30923276 -oh $oracle_home 回退OK
#grid_home xxx 回退失败 提示文件目录不存在。
[root@node19c02 bin]# ./clscfg -localpatch
[root@node19c02 bin]# ./rootcrs.sh -lock --实际操作发现grid_home/bin没有此文件，find / -name 查找到的路径操作。
[root@node19c02 bin]# ./crsctl start crs
再次启动CRS
再次回退，依然failed.
此时，再次进行补丁安装。
使用GRID ,ORACLE 分别补丁安装。
报错提示的目录在节点2不存在，但是在节点1存在，在节点1正常psu安装后的相同位置，使用grid用户，将整个目录cp过来即可。
[oracle@node1 oneoffs]$ scp * node2:$ORACLE_HOME/inventory/oneoffs/
上述操作进行小结： 可以说走了很多弯路，实际上出现问题后，Oracle 软件回滚后， GI 回滚报错目录不存在，此时直接从节点1 scp目录拷贝后，GI回滚， 再次进行补丁安装即可。 上述操作走了很多弯路。
再次进行补丁安装。
先安装GI gi_home opatchauto xxx
在安装ORACLE oracle_home opatchauto xxx
最后数据库 执行sql ok 完美。