Opatch Archive Utility

Wenn man regelmäßig die Critical Patch Updates (CPUs) einspielt, wächst das ORACLE_HOME stetig an. Der Grund ist, dass Opatch alle Dateien, die modifiziert oder ersetzt werden, für das Rollback des Patches aufheben muss. Opatch, legt dafür entsprechende Archive unter $ORACLE_HOME/.patch_storage an. Wenn Oracle Grid Infrastruktur zum Einsatz kommt und für das Patching opatchauto genutzt wird, gibt es zusätzlich ein Verzeichnis $ORACLE_HOME/.opatchauto_storage.

ls $ORACLE_HOME/.patch_storage
29517242_Apr_17_2019_23_27_10      29585399_Apr_9_2019_19_12_47     29774421_Jun_11_2019_04_07_14     
29834717_Jul_10_2019_02_09_26      31771877_Oct_7_2020_21_34_19     32067171_Dec_2_2020_09_24_57
32218454_Jan_14_2021_16_24_38      32399816_Mar_9_2021_06_16_02     32545013_Apr_16_2021_07_40_05
33192694_Sep_14_2021_16_48_27      33192793_Oct_15_2021_07_09_52    33515361_Jan_13_2022_06_14_07
33529556_Jan_9_2022_21_15_36       33561310_Jan_5_2022_08_13_10     interim_inventory.txt
LatestOPatchSession.properties     NApply                           newdirs.txt
record_inventory.txt

Wie viel Platz wird dabei belegt?

du -sh $ORACLE_HOME/.patch_storage
12G /u01/app/oracle/product/19.0.0/dbhome_ee/.patch_storage

Da kommen pro CPU schon mal 1-2GB zusammen, und mit der Zeit belegen die alten Dateien deutlich mehr Platz als das aktuelle ORACLE_HOME.

Die Idee, dieses Verzeichnis einfach zu löschen, kann beim Einspielen des nächsten Patches zu Problemen führen. Wenn ein Patch einen anderen ersetzt, kann es sein, dass zuerst ein Rollback erfolgt - dazu werden die Files in $ORACLE_HOME/.patch_storage benötigt - hier ein Beispiel, wie das aussehen kann:

Rollback von Interimpatch "32902635" aus OH "/u01/app/oracle/product/19.0.0/dbhome_ee" wird durchgeführt
Patching von Komponente oracle.rdbms, 19.0.0.0.0...
RollbackSession Interimpatch '32902635' wird aus Bestand entfernt

Sofern kein Rollback nötig ist, legt opatch einfach ein neues Verzeichnis an. Trotzdem ist es empfehlenswert, die nicht mehr benötigten Patch-Archive sauber zu beseitigen. In einem Blog zu Thema schreibt Mike Dietrich "Don’t wipe it out!"

Bei Oracle gibt es in diesem Zusammenhang einen Enhancement Request 31138227 – $OH/.PATCH_STORAGE KEEP N-1 VERSIONS ONLY FOR BETTER SPACE CONSUMPTION. Auf Grund dieses Requests hat Oracle beginnend mit Opatch Version 26 (zB: 12.2.0.1.26) die Option archive utility eingeführt.

opatch util archive -help
Oracle Interim Patch-Installationsprogramm Version 12.2.0.1.28
…
OPTIONS
      -patches
             A comma separated list of patches to be given for
             archive.

      -archive_dir
             Specify custom storage path to store the patches
             which are going to be archived.
…

Damit ein Rollback möglich ist, sollte keine Patches gelöscht werden, die seit dem letzten - nicht dem aktuellen - Critical Patch Update eingespielt wurden. Auch der letzte CPU sollte aufgehoben werden.

Wie findet man entsprechende Kandidaten zum archivieren?

Eine Liste aller aktuell nicht mehr benötigten Patches lässt sich finden mittels

opatch lsinv -inactive

allerdings kann die sehr lange werden. Um einen Überblick zu bekommen, können die Patch descriptions heraus gefiltert werden.

$ opatch lsinv -inactive | grep description
ARU platform description:: Linux x86-64
Patch description:  "Database Release Update : 19.13.0.0.211019 (33192793)"
Patch description:  "OJVM RELEASE UPDATE: 19.13.0.0.211019 (33192694)"
Patch description:  "Database Release Update : 19.11.0.0.210420 (32545013)"
Patch description:  "OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)"
Patch description:  "Database Release Update : 19.10.0.0.210119 (32218454)"
Patch description:  "OJVM RELEASE UPDATE: 19.10.0.0.210119 (32067171)"
Patch description:  "Database Release Update : 19.9.0.0.201020 (31771877)"
Patch description:  "OJVM RELEASE UPDATE: 19.4.0.0.190716 (29774421)"
Patch description:  "Database Release Update : 19.4.0.0.190716 (29834717)"
Patch description:  "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
Patch description:  "Database Release Update : 19.3.0.0.190416 (29517242)"

Der letzte nicht mehr benötigte CPU ist der vom Oct 2021 (19.13) - der sollte für ein Rollback vorgehalten werden.

opatch util archive -patches 32545013,32399816,32218454,32067171,31771877,29774421,29834717,29585399,29517242 \
       -archive_dir /u02/app/stage/19c/opatch_archive
…
Invoking utility "archive"

Archiving Patch - 31771877 ....
Sucessfully archived patch - 31771877 in /u02/app/stage/19c/opatch_archive/31771877_Oct_7_2020_21_34_19.zip
…
Succesfully verified the created archive. Deleting the original patch from  - 
/u01/app/oracle/product/19.0.0/dbhome_ee/.patch_storage/31771877_Oct_7_2020_21_34_19
…
Patch archive operation completed successfully.

Wie viel Platz benötigt der $ORACLE_HOME/.patch_storage jetzt?

du -sh $ORACLE_HOME/.patch_storage
4,6G /u01/app/oracle/product/19.0.0/dbhome_ee/.patch_storage

Wie viel Platz belegt das OPatch Archive jetzt?

du -sh /u02/app/stage/19c/opatch_archive
2,9G /u02/app/stage/19c/opatch_archive

Spannend ist, dass $ORACLE_HOME/.patch_storage von 12GB auf 4,6GB verkleinert wurde, im Archiv aber nur 2,9GB belegt sind. Der Grund dafür ist, dass Oracle die Verzeichnisse im Archiv zipped.

ls /u02/app/stage/19c/opatch_archive
29517242_Apr_17_2019_23_27_10.zip  29834717_Jul_10_2019_02_09_26.zip  32218454_Jan_14_2021_16_24_38.zip
29585399_Apr_9_2019_19_12_47.zip   31771877_Oct_7_2020_21_34_19.zip   32399816_Mar_9_2021_06_16_02.zip
29774421_Jun_11_2019_04_07_14.zip  32067171_Dec_2_2020_09_24_57.zip   32545013_Apr_16_2021_07_40_05.zip

Versucht man einen archivierten Patch zurück zu rollen (Rollback), kommt folgender Fehler

opatch rollback -id 31771877

...
Patches will be rolled back in the following order:
  31771877
Prerequisite check "CheckRollbackable" failed.
Possible causes are:
The patch can not be rolled back
No read or write permission to ORACLE_HOME/.patch _storage
The ORACLE_HOME/.patch_storage file may have been removed.
The details are:
***************************************************
Following patches are archived:
31771877
Please follow the instructions below to unarchive the patches before proceeding with current Opatch operation 
(as /u01/app/oracle/product/19.0.0/dbhome_ee owner).
Step 1: opatch util unarchive -patches 31771877
Step 2 : Resume/Rerun current Opatch operation: opatch rollback -id 31771877 -invPtrLoc /u01/app/oracle/product/19.0.0/dbhome_ee/oraInst.loc

Wird einer der Patches doch noch benötigt, kann er auch aus dem Archive geholt werden:

opatch util unarchive -patches 32545013,32399816

Bekannte Probleme bei der Nutzung von opatch archive utility

Keine Leerzeichen bei der Angabe der Patches in der Liste (also nicht 32545013, 32399816 sondern wirklich 32545013,32399816), sonst kommt der Error Code 14.
Ist im Archive Verzeichnis nicht ausreichend Platz, kommt Error Code 73.

Breadcrumb