Oracle 10g CPU einspielen

14. Januar 2009 · Anwendungen · andreas · Kein Kommentar

Das Einspielen der Critical Patch Updates (CPUs) in eine Oracle-Datenbank erfolgt mittels des Oracle-eigenen Utilities “OPatch”, welches standardmäßig im Verzeichnis “$ORACLE_HOME/OPatch” zu finden ist. Eine Übersicht der Funktionsweise und Bezugsquellen von OPatch findet sich in der “OPATCH FAQ” im Oracle Metalink.

Grundlegende Informationen zur eingesetzen Datenbank lassen sich im laufenden Betrieb über eine einfache SQL-Abfrage ermitteln:

SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Release 10.2.0.3.0 - 64bit Production PL/SQL Release 10.2.0.3.0 - Production CORE 10.2.0.3.0 Production TNS for Solaris: Version 10.2.0.3.0 - Production NLSRTL Version 10.2.0.3.0 - Production

Eine Auflistung aller bisher einsgespielten Patches gibt es über den Befehl

opatch lsinventory

ermitteln, der aber leider nur die Patch-Nummern, nicht aber die Klartextnamen (wie z.B. “CPU April 2008”) ausgibt. Wer nur die letzte große Änderung an seiner Datenbank wissen will - mittels einer SQL-Abfrage wie

SQL> select action_time, comments, id from dba_registry_history; ACTION_TIME COMMENTS ID ------------------------------------------------------------ 20-JUN-07 02.31.54.218693 PM CPUApr2007 5901891

gelangt man an die Information.

Vor dem Einspielen von Patches sollte immer auf die neuste OPatch-Version (Metalink ID 224346.1 “Where Can I Find the Latest Version of OPatch?”) aktualisiert werden. Hierzu wird das entsprechende Paket heruntergeladen und nach einer Sicherung der Vorgängerversion die “.zip”-Datei im “$ORACLE_HOME”-Verzeichnis entpackt.

cd $ORACLE_HOME mv OPatch Opatch.backup unzip p<Patchnummer>_<Oracle Version>_<Betriebssystem>.zip

Die erfolgreiche Installation kann mittels

cd OPatch ./opatch version

überprüft werden.

Anschließend kann es an das Herunterladen des CPUs gehen. Die jeweiligen CPUs sind unter “Critical Patch Updates and Security Alerts” direkt von der Oracle Website verlinkt. In dem jeweiligen Alert findet sich dann in der Regel der benötigte Link, mit dessen Hilfe man zur Availability Matrix gelangt, einer Tabelle, in der die jeweiligen Patchnummern angegeben sind, nach denen man im Metalink unter “Patches & Updates”, “Simple Search” suchen kann. Ebenfalls mit Herunterladen (und am besten als Notiz- und Kontrollzettel neben die Tastatur legen) sollte man das zugehörige Patch-Readme, das die Vorgehensweise und mögliche Fehlersituationen detailliert beschreibt.

Die CPUs sind kumulativ, d.h. alle Patches aus vorherigen Security Alerts und CPUs sind in den jeweiligen Nachfolgern enthalten, so daß es vollkommen ausreicht, den aktuellsten CPU einzuspielen. Bereits eingespielte Patches werden von OPatch einfach übersprungen.

Vor dem Patchen müssen alle Prozesse, die zum zu patchenden $ORACLE_HOME gehören, beendet werden. Dies sind in der Regel die Datenbank, das Enterprise Manager Database Control sowie der Listener:

sqlplus /nolog SQL> connect / as sysdba; SQL> shutdown immediate; SQL> exit emctl stop dbconsole lsnrctl stop

Bevor es an das endgültige Einspielen geht, ist sicherzustellen, daß die Programme “make”, “ar”, “ld” und “nm” im Pfad verfügbar sind, wofür u.U. noch der Pfad entsprechend erweitert werden muß:

export PATH=$PATH:/usr/ccs/bin

Ebenfalls sinnvoll ist, vor dem Einspielen des Patches eine Liste der ungültigen Objekte erzeugen zu lassen um diese mit der Liste der ungültigen Objekte nach Einspielen des Patches abgleichen zu können:

SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS= 'INVALID';

Anschließend kann mit dem Einspielen begonnen werden:

unzip p<Patchnummer>_<Oracle Version>_<Betriebssystem>.zip cd <Patchnummer> $ORACLE_HOME/OPatch/opatch napply -skip_subset -skip_duplicate

Im Idealfall läuft OPatch nun problemlos durch oder spuckt nur ein paar Warnungen aus, dann kann mit den Nacharbeiten begonnen werden, die zu dem Patchvorgang gehören und meist aus dem Ausführen einiger Shellskripte und SQL-Skripte bestehen.

Anschließend können Listener und Enterprise Manager Database Control wieder gestartet werden, die Datenbank wurde im Laufe der Nacharbeiten bereits gestartet und muß u.U. nur noch in den Zustand “open” gebracht werden.

lsnrctl start emctl start dbconsole