Kategorien
Anwendungen

Plattenplatz beim Ausführen von OPatch

Während des Einspielens von Critical Patch Updates benötigt OPatch zum Sichern der zu aktualisierenden Module reichlich Festplattenplatz, so daß es passieren kann, daß während des Einspielvorgangs nicht mehr genügend Plattenplatz zur Verfügung steht.

Mit dem Howto ID 550522.1 „How To Avoid Disk Full Issues Because OPatch Backups Take Big Amount Of Disk Space.“ gibt Oracle gezielte Hinweise, wie im Falle des Falles zu verfahren ist und weist auch auf die „util“-Funktion von OPatch hin.

$ opatch util cleanup

räumt auf und löscht alle Daten des „$ORACLE_HOME/.patch_storage“-Verzeichnisses, die nicht für einen Rollback von Interim-Patches notwendig sind.

Kategorien
Anwendungen

Oracle Archiver-Stuck beheben

Wenn Oracle der Platz zum Speichern der Redo-Logs ausgeht, kommt es zu einem sog. Archiver Stuck.

Reicht auch das Löschen des vom Admin meist in weiser Voraussicht angelegten Dummy-Files nicht, so kann der Speicherort für die Logs kurzfristig umgebogen werden:

ALTER SYSTEM ARCHIVE LOG STOP;
ALTER SYSTEM SET LOG_ARCHIVE_DEST='woauchimmer';
ALTER SYSTEM ARCHIVE LOG START;

Anschließend können die alten Logs in Ruhe in Sicherheit gebracht und Platz geschaffen werden, bevor mit obiger Befehlsfolge der Speicherort wieder auf das ursprüngliche Ziel zurückgestellt wird.

Wer genauere Infos zum aktuellen Status seiner Archive-Logs erhalten will, kann sich diese mit dem Befehl

ARCHIVE LOG LIST

beschaffen. Eine ausführliche Abhandlung zum Thema „Managing Archived Redo Logs“ gibt’s im Oracle Database Administrator’s Guide.

Kategorien
Anwendungen

Oracle Database recovery

Stellt sich Oracle beim Datenbank-Recovery etwas umständlich an, so muß man etwas tiefer in die Trickkiste greifen:

Erfahrungsgemäß läuft ein

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

meist damit gegen die Wand, daß Oracle versucht, auf ein nicht existierendes, archiviertes Logfile zuzugreifen. Ergebnis sind in der Regel der Fehler

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '<woauchimmer>system01.dbf'

was aber nicht unbedingt bedeutet, daß sich das Problem tatsächlich auf die eine Datei beschränkt.

Sollte dies der Fall sein, muß für ein erfolgreiches Recovery noch das aktuelle Redo-Log verwendet werden. Hierzu ist zuerst das aktuelle Log zu ermitteln

SELECT member FROM v$logfile , v$log WHERE v$log.status='CURRENT' AND v$logfile.group# = v$log.group#;

anschließend nochmals ein Recovery zu starten, hierbei allerdings weder ‚AUTO‘ noch ‚CANCEL‘ zu wählen sondern das soeben ermittelte Logfile anzugeben.

RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Hat alles geklappt, sollte ein

ALTER DATABASE OPEN RESETLOGS;

zum gewünschten Erfolg führen.

Kategorien
Anwendungen

Oracle 10g CPU einspielen

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