Früher gab es für jeden Patch eine eigene Installationsanweisung, in der detailliert beschrieben war, welche Dateien in welche Ordner zu kopieren waren und welche Statements ausgeführt werden sollten. Da dieser manuelle Prozess bei der Installation wie auch beim Zurückrollen sehr fehleranfällig war, musste nach einer einfacheren Methode gesucht werden.

Für Patch Sets gab es bald die Möglichkeit, die Installation mit eigenen Installationsroutinen und somit dem Oracle Universal Installer durchzuführen. Dies stellte keine Lösung für OneOff Patches dar, welche zügig installiert werden sollten - ohne langwierige Prüfprozesse eines Installers.

Also entwickelte Oracle das Oracle Patch Utility, einen Satz von Perl Skripten und Java Klassen, zum Einspielen und Zurückrollen von Patches. Ein Patch enthält eine bestimmte Anzahl von Konfigurationsdateien im XML Format, in denen alle Informationen des Patches und des Patchvorgangs enthalten sind, wie zum Beispiel :

• Für welches Betriebssystem ist der heruntergeladene Patch
• Welche Dateien benötigen ein Backup
• In welches Verzeichnis müssen die Patch Dateien kopiert werden
• Welche Link Befehle sind auszuführen
• Abhängigkeiten zu anderen Patches
• Welche SQL Skripte sind auszuführen

Das OPatch Utility selbst ist nicht enthalten, da dies enen zusätzlichen "Ballast" darstellen würde.!

Diese XML Dateien befinden sich im Verzeichnis "etc" des entpackten Patch. So kann man beispielsweise in der Datei inventory.xml unter "PatchID/etc/config" einige Informationen zum Patch finden. Einfacher als allerdings die XML Datei selber zu entschlüsseln, können die enthaltenen Daten auch mit OPatch ausgelesen werden:

$ cd /tmp/10317487
$ $ORACLE_HOME/OPatch/opatch query -all
...
 Patch created on 4 Feb 2011, 01:10:15 hrs PST8PDT
 Need to shutdown Oracle instances: true
 Patch is roll-backable: true
 Patch is a "Patchset Update": false
 Patch is a rolling patch: true
 Patch has sql related actions: false
 Patch is an online patch: false
 Patch is a portal patch: false
 Patch is an "auto-enabled" patch: false

 List of platforms supported:
   46: Linux Intel

 List of bugs to be fixed:
   10317487: RMAN CONTROLFILE BACKUP FAILS WITH ODM ERROR ORA-17500 AND ORA-245

 This patch is a "singleton" patch.

 This patch belongs to the "db" product family

 List of executables affected:
   ORACLE_HOME/bin/oracle

 List of optional components:
   oracle.rdbms:  11.2.0.2.0

 List of optional actions:
   Update /opt/oracle/product/11.2.0.2/db/lib/libserver11.a with /kcc.o
   cd /opt/oracle/product/11.2.0.2/db/rdbms/lib
     ; make -f ins_rdbms.mk ioracle ORACLE_HOME=/opt/oracle/product/11.2.0.2/db
...

Hier erkennt man unter anderem, ob der Patch ein "RAC Rolling" Patch ist, SQL enthält, online eingespielt werden kann und ob eine Zurücknahme (Rollback) des Patches möglich ist.

Neben den oben schon erwähnten Befehlen "query" und "-help" sind die wichtigsten Befehle

• "lsinv" zum Listen der bereits installierten Komponenten
• "apply" zum Einspielen eines Patches
• "rollback" um einen Patch gegebenfalls wieder zurückzunehmen
• "prereq" zum Prüfen auf mögliche Konfilkte

Insbesondere bei PSUs wird gerade das "prereq" Kommando explizit in der Readme erwähnt und gehört zum Patch Vorgang.

OPatch zeigt mit Hifle des "lsinventory" bzw. kurz "lsinv" Befehl alle installierten Komponenten an, die im entsprechenden Inventory Verzeichnis des ORACLE_HOMEs zu finden sind. Wird "lsinv" ohne Parameter ausgeführt, so zeigt er lediglich die Inhalte des aktiven ORACLE_HOMEs an, d.h. OPatch greift nur auf das Inventory im jeweiligen ORACLE_HOME zu und schaut nicht im globalen Inventory nach, welche Produkte/Versionen sonst noch installiert sind. Diese lokale Abfrage hat jedoch den Vorteil, dass die Ausgabe hier mit "-detail" sehr detailliert erfolgen kann.

Möchte man hingegen die Informationen aller installierten ORACLE_HOMEs erhalten, so führt man OPatch mit der Option "-all" aus. Hier ist die Ausgabe nicht so detailliert, aber man erhält eine Übersicht über die ORACLE_HOMEs auf den kompletten Servern - vorausgesetzt, alle Homes sind im Globalen Inventory (/etc/oraInst.loc) registriert.

$ $ORACLE_HOME/OPatch/opatch lsinv -all
...
List of Oracle Homes:
  Name          Location
   Ora11g_gridinfrahome2         /opt/11.2.0.2/grid
   OraDb11g_home1         /opt/oracle/product/11.2.0.2/db

Installed Top-level Products (1):

Oracle Database 11g                                                  11.2.0.2.0
There are 1 products installed in this Oracle Home.

Interim patches (3) :

Patch  10317487     : applied on Tue May 17 18:31:27 CEST 2011
Unique Patch ID:  13398946
...
Patch  11724916     : applied on Tue May 17 17:38:06 CEST 2011
Unique Patch ID:  13610335
...
Patch  12311357     : applied on Tue May 17 17:30:57 CEST 2011
Unique Patch ID:  13610335

...

Eine Besonderheit gibt es noch bei RAC Umgebungen. Mit "-all_nodes" ist es möglich, die lokalen Inventories auch Knoten übergreifend zu vergleichen. Hierbei werden nicht nur die installierten Patches aufgelistet, sondern auch eine Checksumme des Oracle Executables verglichen:

$ $ORACLE_HOME/OPatch/opatch lsinv -all_nodes
...
Rac system comprising of multiple nodes
  Local node = bumucsvm1
  Remote node = bumucsvm2
  Remote node = bumucsvm3
...
Binary & Checksum Information
==============================

 Binary Location : /opt/oracle/product/11.2.0.2/db/bin/oracle

 Node                   Size                    Checksum
 ----                   ----                    --------
 bumucsvm1              189044692               287469405
 bumucsvm2              189044692               287469405
 bumucsvm3              189044692               287469405
--------------------------------------------------------------------------------

Die Installation von Patches ist im Normalfall mit einem Schritt getan. Es ist aber durchaus empfehlenswert, vor der Patch Installation einen Check auf mögliche Konflikte durchzuführen und das Readme des jeweiligen Patches zu konsultieren. Sind dort keine speziellen Instruktionen genannt, lässt sich der Patch mit folgenden 2 Befehlen prüfen und installieren, nachdem man sich im entpackten Verzeichnis des Patches positioniert hat:

$ cd /tmp/10317487
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir .
$ $ORACLE_HOME/OPatch/opatch apply

Das Einspielen eines Patches erfolgt dabei immer in mindestens 2 Schritten: Backup der zu ändernden Dateien nach .patch_storage im ORACLE_HOME und dann erst die eigentliche Installation der Dateien und das Linken falls notwendig.

Manche Patches erlauben auch das direkte Ausführen von SQL nach der Patch Installation. Dies kann man erreichen, indem man dem apply Befehl ein "-runSql" mitgibt. Ob dies allerdings überhaupt möglich ist, steht im Readme des Patches.

Gibt man übrigens bei RAC Homes nicht den speziellen "-local" Flag mit, so wird der Patch automatisch auf alle anderen Knoten mit verteilt (nach vorhergehender Bestätigung). Die Arbeit der Neukompilierung wird aber nur auf dem ersten Knoten durchgeführt, die Executables werden danach einfach auf die anderen Knoten kopiert. Dies kann eine erhebliche Zeitersparnis sein.

Das Zurücknehmen (auf englisch Rollback) eines Patches funktioniert etwas anders. Hierbei wird nicht die Patch Nummer des Patches benötigt, sondern die eindeutige "Unique Patch ID". Diese erhält man nur über die Auflistung des Inventories mit "opatch lsinv" (siehe oben). Mit Hilfe dieser ID ist ein Zurückrollen des Patches dann möglich:

$ $ORACLE_HOME/OPatch/opatch rollback -id 

Damit ein Rollback eines Patches funktioniert, dürfen selbstverständlich die Originaldateien aus dem .patch_storage Verzeichnis nicht entfernt worden sein!.

Nicht in der Dokumentation erwähnt sind die Funktionalitäten, die über den "opatch util" Befehl zur Verfügung stehen. Dabei findet man gerade hier einige interessante Optionen. Neben der Möglichkeit, SQL eines Patches mit OPatch anzuwenden, einen installierten Patch mit "verify" zu validieren und im RAC Umfeld Remote Befehle oder Lösch- und Kopieraktionen auszuführen, gehört auch ein "cleanup" dazu, welches nicht benötigte Dateien aus dem Backup Verzeichnis löscht, ohne dabei die Rollback Funktionalität zu beeinträchtigen:

$ cd /tmp/10317487          
$ $ORACLE_HOME/OPatch/opatch util verify -ph .
...
Verifying the update...
Inventory check OK: Patch ID 10317487 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 10317487 are present in Oracle Home.
Patch has been verified successfully.
...
$ $ORACLE_HOME/OPatch/opatch  cleanup
...
Invoking utility "cleanup"
OPatch will clean up 'restore.sh,make.txt' files and 'rac,scratch,backup' directories.
You will be still able to rollback patches after this cleanup.
Do you want to proceed? [y|n]
y
User Responded with: Y
Size of directory "/opt/oracle/product/11.2.0.2/db/.patch_storage" before cleanup is 627661971 bytes.
Size of directory "/opt/oracle/product/11.2.0.2/db/.patch_storage" after cleanup is 185730080 bytes.

UtilSession: Backup area for restore has been cleaned up. For a complete list of files/directories
deleted, Please refer log file.
...

Eine Sonderstellung nimmt der Rolling Upgrade eines RAC Clusters ein - da hier der Befehl "opatch auto" zum Einsatz kommt, der im Gegensatz zu den anderen Befehlen vom Benutzer root verwendet wird. Wie dieses Kommando genau ausgeführt wird und wie man ein manuelles Upgrade für eine Neuinstallation durchführt, werde ich in einem der nächsten Tipps beschreiben.