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 …
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 …
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 …
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 …
