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