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

之前的上一篇文章中关于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 完美。