Mehr als nur Patching - Das Oracle Patch Utility
von Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG
Fast jeder, der schon einmal einen Datenbank Patch installiert hat, kennt eigentlich das Oracle Patch Utility - kurz OPatch.
Da alleine schon der Vorgang einen Patch zu installieren, nicht zu den angenehmsten Erfahrungen gehört, verbinden
viele mit OPatch nicht unbedingt Positives. Dass vor jedem Patch immer erst die aktuelle Version des OPAtch Utilities geladen werden muss,
trägt auch nicht gerade zu einer verbesserten Beziehung zu OPatch bei. Eigentlich zu Unrecht,
denn neben den Vorteilen einer Tool gestützten Patch Installation hat OPatch auch noch einige andere nette Funktionalitäten,
über die nur selten gesprochen wird.
Genau hier möchte ich mit diesem Artikel ansetzen und neben grundsätzlichen Informationen auch noch den ein oder anderen OPatch Tipp mitgeben. Hintergrundinformationen zu OPatch
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 :
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. Aufruf von OPatch
Will man mit OPatch arbeiten, bzw. patchen, so sollte vorher die aktuelle Version von My Oracle Support heruntergeladen werden. Diese findet man unter der Patch Nummer
6880880.
Wie bei allen Oracle Tools muss auch für OPatch die Umgebungsvariable ORACLE_HOME gesetzt sein. Zum Abfragen und Installieren des Patches
ist es dann am einfachsten, sich in das entpackte Patch Verzeichnis zu begeben. OPatch sollte als der User ausgeführt werden, der auch die Oracle
Software Installation durchgeführt hat (und damit die Gruppe "oinstall" als primäre Gruppe besitzt).
Einzige Ausnahme zu dieser Regel, ist der spezielle Vorgang bei einem RAC Cluster, in dem OPatch mit dem Befehl "auto" einen ganzen Cluster "Rolling" Patchen kann: Da zum Starten und Stoppen der Clusterware auf den jeweiligen Knoten Administrator Rechte erforderlich sind, wird in diesem Fall OPatch als root User ausgeführt. OPatch selber verfügt über eine recht gute Hilfefunktion, die die einzelnen Befehle im Detail beschreibt: $ $ORACLE_HOME/OPatch/opatch -help ... Usage: opatch [ -help ] [ -r[eport] ] [ command ] command := apply lsinventory napply nrollback rollback query version prereq util ... $ $ORACLE_HOME/OPatch/opatch lsinventory -help ... DESCRIPTION List the inventory for a particular $ORACLE_HOME or display all installations that can be found. SYNTAX opatch lsinventory [-all ] [-all_nodes] [-bugs_fixed Wichtige OPatch Befehle
Neben den oben schon erwähnten Befehlen "query" und "-help" sind die wichtigsten Befehle
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 applyDas 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 -idDamit 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. ... Graphische Oberfläche
OPatch selber besitzt keine graphische Oberfläche. Allerdings ist das ganze Patch Management in den Enterprise Manager integriert.
Die Integration von MySupport Funktionen in Grid bzw. Cloud Control geht sogar so weit, dass OPatch automatisch vor einem Patch hochgepatched wird (d.h. es ist keine
manuelle Überprüfung und separater Download mehr notwendig), als auch dass die Patchkonflikte direkt im Enterprise Manager geprüft und behoben werden können.
![]() ![]() Ebenfalls sorgt der EM dafür, auch bei mehreren abhängigen Patches die Reihenfolge genau einzuhalten. Rolling Upgrade
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.
Nützliche Links und Referenzen
|