Oracle Database: Upgrade auf 11g

Wie bei jedem Release-Wechsel, so gibt es auch im Rahmen der Einführung von Oracle Database 11g jede Menge für Datenbankentwickler und -administratoren zu tun: Migrati-onspfade wollen getestet und für die produktive Aktualisierung erprobt werden. Die Funk-tionsfähigkeit der Anwendung nach einer solchen Migration ist längst nicht immer ge-währleistet. So führten in vergangenen Versionen Änderungen der internen Struktur des Data Dictionary oder des SQL*NET-Protokolls schon zu Herausforderungen, die im Zuge einer Migration zu bewältigen waren. Doch gut vorbereitet lässt sich eine Aktualisierung der Datenbankversion auf 11g problemlos meistern.
Auf den nächsten Seiten möchte ich Sie mit den gängigen Verfahren vertraut machen; die wichtigsten Verfahren:

• Export und Import
• Manuelles Upgrade mit SQL-Skripten
• Automatisiertes Upgrade mit dem Database Upgrade Assistant (DBUA)

ORACLE Export / Import

Export und Import ist ein einfacher Weg der Aktualisierung. Dabei werden die Daten aus dem Altsystem exportiert und in eine neue Oracle 11g Datenbank importiert.
Wird eine kleine Datenbank transferiert, handelt es sich um eine sehr gute und einfache Option, die oft ohne größere Probleme vonstatten geht. Bei Datenbanken, die mehrere Terabyte Daten speichern, ist der Export und Import der Daten jedoch ein zeitraubender Prozess. Bei einem Wechsel des Zeichensatzes oder der Betriebssystemplattform ist dies oft der einzig gangbare Weg. Aber auch dann, wenn kein direkter Migrationspfad vom alten Release zum neuen für das manuelle Upgrade und den Database Upgrade Assistant unterstützt wird, kann die Migration mit Export / Import eine hilfreiche Abkürzung bieten.
Statt Export und Import kann neuerdings auch Data Pump verwendet werden. Data Pump stellt wie Export und Import ein Verfahren zur Übertragung von Datenbankobjekten bereit, das eine bessere Performance als Export und Import bietet, jedoch bezüglich der Daten-bankversionen einige Einschränkungen aufweist.

Praxistipp

In Oracle Database 11g können Daten ab Oracle V5 importiert werden. Bei einem Plattformwechsel war bis Oracle 10g der Export / Import zwingend erforderlich. Auch bei einem Wechsel des Zeichensatzes ist Export / Import eine geeignete Methode.

Manuelles Upgrade

Bei einem manuellen Ugprade wird die alte Datenbank beibehalten, nur ihre internen Ka-taloge werden auf den neuen Release-Level aktualisiert. Sie wird zunächst heruntergefah-ren, um sie anschließend mit der neuen Oracle 11g-Software zu starten. Dazu müssen einige manuelle Arbeiten durchgeführt werden. Unter anderem sind die internen Base Tables der Datenbank mit SQL-Skripten an das neue Release anzupassen.
Das Skript utlu111i.sql prüft vor dem Upgrade zunächst die Ausgangsdatenbank und gibt anschließend Empfehlungen. Weisen die Ergebnisse des Prüfskripts auf fehlende Migrati-onsvoraussetzungen oder auf eventuell zu erwartende Probleme hin, sind diese zunächst zu beheben.
Danach wird die Datenbank mit der neuen 11g-Software im Upgrade-Modus gestartet, um anschließend mit dem SQL-Skript catupgrd.sql die bestehende Datenbank zu aktualisieren. Dieses Skript passt interne Komponenten und Base Tables für die Nutzung der neuen Software an. Invalide Objekte sollten abschließend mit dem Skript utlrp.sql rekompiliert werden. Den Status nach dem Upgrade kann man mit der Ausführung des Skriptes ut-lu111s.sql prüfen. Alle erforderlichen SQL-Skripts liegen im Oracle-Home-Verzeichnis unter rdbms\admin. Sie werden mit SQL*Plus als Sysdba ausgeführt.

Automatisiertes Upgrade mit dem Database Upgrade Assistant (DBUA)

Möchte man all diese Aufgaben nicht manuell ausführen, kann man auch auf graphische Unterstützung zurückgreifen: Der Database Upgrade Assistant (DBUA) führt alle Aufgaben, die auch bei einem manuellen Upgrade anfallen, per Mausklick konfigurierbar automatisch durch. Auf Knopfdruck erzeugt er sogar eine Sicherung aller Datenbankdatei-en vor dem Upgrade und rollt bei einem Fehlschlag die Datenbank zurück. Dafür hat man nicht dieselbe Kontrolle, wie dies bei einem manuellen Upgrade der Fall ist.

Vor- und Nachteile der einzelnen Migrationsverfahren

Jedes der dargestellten Verfahren bietet Vor- und Nachteile. Welches Verfahren zu wählen ist, hängt von den konkreten Anforderungen im Projekt ab.

Export und Import

Die Migration mit Export und Import bzw. die mit Oracle Data Pump durchgeführte Mig-ration lässt die Original-Datenbank vollständig unberührt. Ein Fallback auf das Alt-System ist so jederzeit möglich. Doch abhängig von der Datenmenge, die zu exportieren und spä-ter auf dem Neu-System zu importieren ist, kann dieser Migrationspfad einige Zeit in An-spruch nehmen. 

Database Upgrade Assistant (DBUA)

DBUA ist ein für das Datenbank-Upgrade hilfreiches Werkzeug. Es unterstützt die Migra-tion über eine graphische Oberfläche und erleichtert so nicht nur „Maus-Schubsern“ die Aktualisierung einer Datenbank. Dabei erkennt es den aktuellen Release-Stand aller Da-tenbanken auf dem System und leitet auf Knopfdruck alle Schritte wie etwa die Prüfung der Migrationsvoraussetzungen und die Durchführung notwendiger SQL-Skripts ein.
Dem Vorteil einer sehr bequemen Handhabung steht der Nachteil der etwas schwierigeren Fehlersuche bei Problemfällen gegenüber. Für Einsteiger ist die Nutzung des DBUA sicher die erste Wahl, während versierte Administratoren möglicherweise das manuelle Upgrade bevorzugen werden.

Manuelles Upgrade mit SQL-Scripts

Wer doch lieber etwas näher am Kern des Systems arbeitet und jeden Schritt selbst kon-trollieren möchte, führt das manuelle Upgrade durch. Dabei werden alle Migrationsschritte  – wie etwa die Prüfung der Migrations¬voraussetzungen sowie die eigentliche Migration selbst – manuell durch den Datenbankadministrator durchgeführt. Das höhere Maß an Kontrolle über jeden einzelnen Schritt ist sicher ein Vorteil. Dafür ist dieser Migrati-onspfad etwas aufwendiger. Er setzt zudem mehr Know-how voraus.

CREATE TABLE AS SELECT 

Der Vollständigkeit halber soll auch dieses Verfahren nicht unerwähnt bleiben. Auch wenn  „CREATE TABLE AS SELECT“ vom Hersteller als möglicher Weg einer Datenmigration angegeben wird, handelt es sich hierbei um keine echte bzw. vollständige Migration. Die-ses SQL-Statement ermöglicht vielmehr, Daten einer Tabelle in eine neue Tabelle zu über-nehmen. So kann beispielsweise eine Kopie der Daten bzw. eines Subsets von Daten des Alt-Systems über einen Datenbank-Link in das Neu-System übernommen werden. Zur Migration kompletter Schemata inklusive aller abhängigen Objekte und Regeln ist dieser Weg weniger geeignet.

Der Migrationsplan

Generell sollte eine Migration bzw. ein Upgrade geplant und die Funktionsfähigkeit der Anwendung nach dem Releasewechsel sorgfältig geprüft werden. Umfangreiche Tests der gesamten Anwendung und nicht zuletzt auch aller Schnittstellen sind im Vorfeld zu absol-vieren. Wer meint, er könne – vielleicht aus Kostengründen – diesen Schritt überspringen, findet sich häufig nach einem Upgrade in überraschenden Situationen wieder. So kann es beispielsweise passieren, dass die Kommunikation über Datenbanklinks zu wichtigen Part-ner-Systemen nicht mehr funktioniert, da mit einer älteren Oracle-Datenbankversion kommuniziert wird, das aktuelle Protokoll dies nicht mehr unterstützt und dafür kein Wor-karound im Vorfeld geschaffen wurde. Auch Probleme mit neuen Zeichensätzen oder Änderungen des Optimizers und daraus folgendes Änderungen eines Ausführungsplanes können massive Probleme verursachen. Sie sollten daher gezielt und wohlüberlegt vorge-hen. Ein sorgfältiger Anwendungstest hütet Ihre Anwender vor unangenehmen Überra-schungen.

1.    Vorbereitungen

• Auswahl des Upgrade-Verfahrens
• Entwicklung und Fertigstellung eines Testplans inklusive aller Anwendungen und Schnittstellen, die auf die Datenbank zugreifen
• Festlegen einer Strategie im Falle eines Fallback

2.    Testen des Upgrades

• Installation des neuen Release in einem neuen Oracle-Home-Verzeichnis
• Durchführung des Upgrades in der Testumgebung
• Festlegung des Verfahrens für das spätere Upgrade der Produktion

3.    Anwendungs- und Schnittstellentest

• Testen aller Anwendungen, die auf die Datenbank zugreifen
• Testen aller ausgehenden und eingehenden Schnittstellen
• Vergleich der Ergebnisse zwischen alter und neuer Umgebung

4.    Beseitigung eventueller Probleme

• Erarbeiten von Lösungen, um eventuelle Anomalien zu beseitigen
• Wiederholung des Anwendungstests (zurück zu Schritt 3)

5.    Upgrade der Produktion

• Ein produktives Upgrade sollte stets erst dann durchgeführt werden, wenn alle An-wendungen  und Schnittstellen, die auf die Datenbank zugreifen, erfolgreich abge-schlossen werden konnten.

Eine Produktionsumgebung sollte niemals – wirklich niemals – ohne vorherige Tests um-gestellt werden. Änderungen in internen Datenstrukturen und Protokollen können dazu führen, dass beispielsweise Schnittstellen nicht funktionieren. Eine nicht vollständig durchgeführte Überprüfung der Funktionsfähigkeit aller Anwendungsteile in einer Test-phase birgt stets das Risiko, dass nach der Aktualisierung unwägbare Probleme auftreten!

Durchführung der Migration mit Export / Import

Das Verfahren über Export / Import ist einfach, doch oft zeitaufwändig. Export/Import bietet jedoch auch einige Vorteile: Bei einem Plattformwechsel oder bei Release-Wechseln, für die kein direktes Upgrade unterstützt wird, ist Export/Import das vermutlich einfachste und schnellste Verfahren. So werden beispielsweise Export-Dumps ab Oracle V5 unterstützt. Und auch bei einem Wechsel des Zeichensatzes ist dieses Verfahren die erste Wahl.
Der Zeitaufwand der Portierung hängt von einigen Faktoren ab. Relevant ist hier vor allem die Datenmenge: Je höher diese ist, desto länger benötigt der Export und auch der Import.
Wird neue Hardware eingesetzt, ist nach dem Export die gesamte Datenmenge auf das neue System zu übertragen. Dabei sind die Export-Dumps immer im Binary-Modus zu transferieren.
Der Export mit dem Befehl exp sollte als System-Benutzer ausgeführt werden. Wichtig ist zudem, den Export mit der niedrigsten beteiligten Datenbankversion zu erzeugen. Der Import selbst wird dann mit dem Befehl imp der Version der Zieldatenbank ausgeführt. In Oracle Database 11g gibt es übrigens keinen exp-Befehl für den Export. Er ist desupportet. Unterstützt wird noch der Befehl imp.
Der Import der Daten benötigt oft etwa zwei- bis dreimal so lange wie der Export. Hinter-grund ist, dass bei einem Import zusätzliche interne Verwaltungstätigkeiten – wie die Iden-tifikation freier Blöcke für das Einfügen der Daten – anfallen.
Um die Performance zu optimieren, lässt sich der SQL-Layer mit einem Direct-Export umgehen. Dabei wird dem Befehl exp der Schalter DIRECT=Y angehängt. Die maximale Zeilenlänge sollte mit dem Schalter RECORDLENGTH auf den Maximalwert von 64 K gesetzt werden (RECORDLENGTH=64KB). Falls Sie keinen Direct-Export nutzen, setzen Sie am besten auch die Größe des Export-Buffers hoch (BUFFER=2M). Die Größe dieses Buffers legt fest, wie viele Datenzeilen bei einem Conventional Export in ein Array ge-fetcht werden können. Sofern unterstützt, kann auch parallelisiert exportiert werden. Der Schalter PARALLEL wird hierzu einfach auf den passenden Parallelisierungsgrad gesetzt.
Hier eine Übersicht möglicher Schalter:

Prüfen Sie Ihre Quellversion auf unterstützte Schalter. Um herauszufinden, welche Schal-ter unterstützt werden, rufen Sie auf Ihrem Quellsystem den Befehl exp mit dem Schalter HELP=Y auf.
Für den Import sollte der Befehl imp Ihres Ziel-Releases verwendet werden. Mögliche Schalter in Oracle Database 11g sind:

Der Import benötigt mehr Zeit als der Daten-Export, sofern exakt dieselbe Hardware ein-gesetzt wird. Doch ist bei einem Hardware-Wechsel davon auszugehen, dass die höhere Leistungsfähigkeit moderner Komponenten für eine weit bessere Performance sorgt. Um eine exakte Aussage über die Zeitdauer zu treffen, ist ein Testlauf erforderlich.

Der Parameter directory benötigt die Angabe eines gültigen Directory-Objektes in der Datenbank.

Eine gute Alternative zu Export/Import ist die Nutzung von Datapump, das eine sehr viel bessere Performance bietet. Datapump steht ab Oracle 10.1.0.2 zur Verfügung. Leider sind Export-Dumps, die mit dem Befehl exp erzeugt wurden, nicht zu Dumps aus Datapump kompatibel. Die Befehle lauten expdp und impdp.

Der Parameter directory benötigt die Angabe eines gültigen Directory-Objektes in der Datenbank.

Migration mit dem ORACLE Database Upgrade Assistant (DBUA)

Ein graphisch geführtes Upgrade bietet der Database Upgrade Assistant (DBUA). Er führt alle notwendigen Schritte automatisch durch. Die Vorgehensweise im Hintergrund entspricht dem des manuellen Upgrades, doch werden alle Prüfungen und Skripts vom DBUA automatisch ausgeführt und die Ergebnisse in der graphischen Oberfläche angezeigt. Features des DBUA sind:

• Die automatische Ausführung aller Prüfungen und Skripts.
• Auf Wunsch wird vorab ein Backup durchgeführt.
• Patch-Upgrades werden ausgeführt.
• Upgrade von ASM ist eingeschlossen.
• RAC-Awareness.

Der Database Upgrade Assistant (DBUA) konfiguriert während des Upgrades den Enterprise Manager Database Control im Secure Mode. Mit dem DBUA 11g kann nun auch Oracle Database Express Edition (Oracle Database XE) auf 11g aktualisiert werden. Als Teil des Upgrades können Data Files der Datenbank auf einen anderen Storage gehoben werden. Die Migration von und zu Automatic Storage Management (ASM) oder auch Oracle File System (OFS) ist damit erheblich vereinfacht. Auch Application Express (APEX) wird während des Upgrade-Vorganges aktualisiert.

DBUA unterstützt Upgrades der Releases Oracle 9i Release 2 (9.2.0.4) und aufwärts sowie Oracle Database 10g Release 1 (10.1) und Release 2 (10.2). Während des Upgrades wer-den alle Dateien der Datenbank vorübergehend auf autoextend gesetzt, d.h. sie erweitern bei Bedarf den im Dateisystem allokierten Speicherplatz. Zum Abschluss der Aktualisie-rung einer Datenbank setzt der DBUA alle Autoextend-Einstellungen zurück; die Einstel-lungen der Data Files vor  dem Upgrade-Prozess werden damit wieder übernommen.
Der Aufruf erfolgt mit dem Befehl dbua im Verzeichnis $ORACLE_HOME/bin.
Praxistipp

Der Betriebssystembenutzer für den Upgrade-Prozess benötigt – sofern Windows als Plattform genutzt wird – das Recht, Stapelverarbeitungsaufträge auszuführen. Dazu wird dem Benutzer in der Systemsteuerung unter Benutzerverwaltung das Recht „Anmelden als Stapelverarbeitungsauftrag“ erteilt. Mit dieser Einstellung legt man fest, welchen Benutzerkonten die Anmeldung für Batchaufträge gestattet wird.

1.    Der Willkommensbildschirm wird geöffnet. Klicken Sie auf „Weiter“.

2.    Sofern eine ASM-Instanz auf dem System besteht, wird das Upgrade von ASM oder einer Datenbank zur Auswahl gestellt (Abbildung 3.2). Falls Sie hier „Da-tenbank“ auswählen und diese Datenbank ASM nutzt, so fragt der DBUA, ob zusätzlich auch die ASM-Instanz aktualisiert werden soll. Es empfiehlt sich je-doch, ASM und Datenbank in zwei Schritten zu aktualisieren. Klicken Sie auf „Weiter“.

3.    Die nächste Seite bietet eine Auswahl aller auf dem System vorhandenen Da-tenbanken an. Hier kann nun die Datenbank ausgewählt werden, die auf die neue Version aktualisiert werden soll. Klicken Sie auf „Weiter“.

4.    Nun wird die Datenbank analysiert. Pre-Upgrade-Prüfungen werden durchge-führt. Unter anderem wird Initialisierungsparameter geprüft oder auch die für das Update erforderliche Größe von 4 MB für Redo Log Files. Dieser Schritt entspricht der Ausführung des Skripts utlu111i.sql. Klicken Sie auf „Weiter“.

5.    Sofern der Tablespace sysaux nicht besteht, wird er angelegt. Die meisten Ei-genschaften dieses Tablespaces lassen sich nicht modifizieren. Dazu zählt bei-spielsweise die Verwendung von Automatic Segment Space Management (ASSM). Doch die Namen und Pfade der Datafiles dieses Tablespaces sowie deren Größe und Erweiterbarkeit können in dieser graphischen Oberfläche fest-gelegt werden. Klicken Sie auf „Weiter“.

6.    DBUA bietet die automatische Ausführung einer Offline-Sicherung an. Schlägt das Upgrade fehl, dient diese Sicherung der Wiederherstellung. Der DBUA er-stellt zusätzlich ein Batch-File mit dem Namen db_name_restore.bat unter Win-dows bzw. db_name_restore.sh unter Unix, das für die Wiederherstellung ver-wendet werden kann. Klicken Sie auf „Weiter“.

7.    Die nächste Seite bietet die Option, Database Control oder Grid Control als Management-Werkzeug zu konfigurieren. Die Verwendung von Grid Control setzt voraus, dass bereits ein Management Agent auf dem System installiert ist. Klicken Sie auf „Weiter“.

8.    Es folgen Seiten, auf denen Kennworte für Datenbankbenutzer, das Ziel der Flash Recovery Area und zu verwendende Listener für die Instanzregistrierung festgelegt werden. Abschließend zeigt die Summary Page eine Zusammenfas-sung der ausgewählten Optionen. Prüfen Sie diese genau, bevor Sie mit dem nächsten Schritt fortfahren. Klicken Sie auf „Weiter“.

9.    Das Upgrade wird nun durchgeführt. Das Fortschrittsfenster gibt genaue Aus-kunft über die gerade ausgeführten Schritte (siehe Abbildung 3.4). Klicken Sie auf „Weiter“.

10.    Der Abschlussbericht zeigt Ergebnisse, die denen des Skripts utlu111s.sql entsprechen (siehe Abbildung 3.5). Klicken Sie auf „Weiter“.

Manuelle Migration

Das manuelle Upgrade und die Aktualisierung einer Datenbank mit dem DBUA haben einiges gemeinsam. Im Grunde führt der DBUA die SQL-Skripten mit einer graphischen Unterstützung aus, die bei einem manuellen Upgrade mit expliziten Befehlen aufgerufen werden. Daher haben das manuelle  und das mit dem DBUA ausgeführte Upgrade einige Gemeinsamkeiten.

Migrationspfade für das manuelle Upgrade bzw. den DBUA

Je nachdem, welche Oracle-Version Sie einsetzen, kann direkt oder nur indirekt aktualisiert werden. Einige ältere Releases erfordern, dass zunächst ein Zwischenschritt auf ein unterstütztes Release durchgeführt wird. Versionen ab 9.2.0.4 aufwärts unterstützen jedoch die direkte Migration auf Oracle DB 11g. Für die Oracle Clusterware gilt: Möchten Sie auf Version 11.x direkt migrieren, muss mindestens 10.2.0.3 oder höher eingesetzt werden.

Hier eine Zusammenfassung:

7.3.3 oder niedriger      7.3.4     9.2.0.8    11.1

8.0.5 oder niedriger      8.0.6     9.2.0.8    11.1

8.1.7 oder niedriger      8.1.7.4   9.2.0.8    11.1

9.0.1.3 oder niedriger    9.0.1.4   9.2.0.8    11.1

9.2.0.3 oder niedriger    9.2.0.8   11.1

Prüfung der Systemvoraussetzungen

Vor dem Upgrade werden nun wichtige Voraussetzungen abgeprüft. Die hieraus resultie-renden Warnungen sind hilfreich, um Probleme bereits im Vorfeld zu beseitigen. Auch das Fehlermanagement während des Upgrade-Prozesses hat sich verbessert. So werden Fehler gesammelt  und für jede einzelne Komponente im Post Upgrade Status-Tool angezeigt.

Upgrade und Downgrade

Oracle DB 11g führt einige Verbesserungen im Umfeld der Datenbank-Aktualisierung ein. So gibt es nun neben dem SQL-Skript für das Upgrade (catupgrd.sql) auch eines für ein Downgrade (catdwgrd.sql ), also den Weg zurück auf das Ursprungsrelease. Er steht einem offen, solange der Kompatibilitätsparameter compatible noch nicht auf 11g angeboten wurde. Beide, das Upgrade- wie auch das Downgrade-Skript, sind auf Patches wie auf Major Releases anwendbar.

Beispiel eines manuellen Upgrades

Ein manuelles Upgrade wird nach folgenden Schritten vollzogen:

1.     Backup der Software
2.     Installation der Software
3.     Implementation aller aktuellen Patches
4.     Backup der Datenbank
5.     Statistiken erzeugen
6.     Anlegen des Tablespaces sysaux
7.     Pre-Upgrade-Skript
8.     Neustart der Datenbank im Upgrade-Modus
9.     Upgrade der Datenbank
10.    Post-Upgrade-Skript

Backup der Software

Erzeugen Sie eine Komplettsicherung des Systems, um ein Fallback im Fehlerfall zu erleichtern.

Installation der Software

Alle Optionen wie Label Security und Partitioning, die in der alten Datenbank-Umgebung installiert waren, sollten ebenfalls für die 11g-Installation ausgewählt werden. Informatio-nen zu verwendeten Optionen finden Sie in der View v$option:

sqlplus> set pages 3000
sqlplus> col parameter format a30
sqlplus> col value format a20
sqlplus> select * from v$option;

Implementation aktueller Patches

Zusätzlich sollten alle aktuellen Patches implementiert werden.

Backup der Datenbank vor dem Upgrade

Das Backup der Datenbank kann gemäß den üblichen Sicherungsverfahren durchgeführt werden. Am besten erzeugen Sie ein Full Backup im Offline Modus. Die Wiederherstel-lung der Datenbank ist damit sicherlich am einfachsten

Statistiken erzeugen

Sofern keine Dictionary-Statistiken bestehen, kann das Upgrade signifikant mehr Zeit in Anspruch nehmen. Falls keine aktuellen Statistiken bestehen, können diese noch erzeugt werden:

sqlplus> execute dbms_stats.gather_dictionary_stats;

sqlplus> execute dbms_stats.gather_schema_stats 
   1           (‘SYS’, 
   2             options            => ‘GATHER’,
   3             estimate_percent   => dbms_stats.auto_sample_size,
   4             method_opt         => `FOR ALL COLUMNS SIZE AUTO’, 
   5             cascade            => TRUE);

sqlplus> execute dbms_stats.gather_schema_stats 
   1           (‘SYSMAN’, 
   3             options            => ‘GATHER’,
   4             estimate_percent   => dbms_stats.auto_sample_size,
   5             method_opt         => `FOR ALL COLUMNS SIZE AUTO’, 
   6             cascade            => TRUE); 

Anlegen des Tablespace sysaux

Sofern der Tablespace sysaux nicht schon besteht, muss er erzeugt werden:

SQL> 
 1   create tablespace sysaux2
 2   datafile 'c:\temp\test' size 250M
 3   extent management local 3   segment space management auto; 

Pre-Upgrade-Skript

Oracle stellt einige SQL-Skripts für das Upgrade bereit, die nach der Installation der 11g-Software im Unterverzeichnis rdbms/admin im  neuen Oracle-Home zu finden sind. Füh-ren Sie zunächst das Pre-Upgrade-Skript in der alten Umgebung aus. Sie finden es unter ORACLE_HOME/rdbms/admin/utlu111i.sql. Dieses Skript untersucht die Datenbank auf Erfüllung der Installationsvoraussetzungen und gibt einige wichtige Hinweise wie die zur Änderung der Parametrisierung. Komponenten und Platzbedarf, der Tablespace sysaux und die Timezone-Version werden genau untersucht. Bei Bedarf wird auch ein Cluster-Check durchgeführt. Prüfen Sie die Ausgabe genau! Ernste Probleme sollten vorab beho-ben, Warnungen zumindest ernsthaft untersucht werden. 

Die Ausgabe sieht etwa wie folgt aus:

Die Ausgabe dieses Reports gibt Hinweise auf Punkte wie die Speicheranforderungen wichtiger Tablespaces wie System oder Sysaux. Um Probleme mit Speicherengpässen zu vermeiden, empfiehlt es sich, mindestens je ein Datafile eines jeden Tablespaces vorüber-gehend auf autoextend zu setzen.

Weitere wichtige Hinweise beziehen sich auf die Adjustierung der Datenbankparameter. Nachdem alle Warnungen überprüft und entsprechende Änderungen vorgenommen wur-den, sollte das Pre-Upgrade-Skript erneut durchgeführt und dessen Ausgabe überprüft werden. Erst wenn die Ausgabe auf keinerlei Probleme mehr hinweist, sollte mit dem nächsten Schritt fortgefahren werden.

Neustart der Datenbank im Upgrade-Modus

Die Datenbank muss unbedingt sauber geschlossen werden. Dazu bietet sich die Verwen-dung von shutdown immediate an.

Sofern Sie Windows als Betriebssystem nutzen, beenden Sie auch den Datenbank-Dienst. Der Dienst muss anschließend mit dem Befehl oradim gelöscht werden. Danach müssen Sie ihn mit dem Befehl oradim aus dem neuen Oracle-Home unter 11g neu erstellen.

Während der Neuerstellung des Dienstes schreibt oradim ein Logfile in das Verzeichnis %ORACLE_HOME%\database.

Denken Sie daran, Umgebungsvariablen ORACLE_HOME und PATH, unter Unix auch LD_LIBRARY_PATH, an die neue Umgebung anzupassen. Die Variable ORACLE_SID muss zudem auf die richtige Instanz für das Upgrade zeigen.

Der Start der Datenbank muss nun im Upgrade-Modus erfolgen:

Im Upgrade-Modus werden unter anderem Fehlermeldung wie „ORA-00942 table or view does not exist“ unterdrückt. Die Logfiles werden so wesentlich übersichtlicher. Zudem deaktiviert der Upgrade-Modus die Ausführung von System-Triggern und setzt Job Queues vorübergehend auf 0.

Upgrade der Datenbank

Das eigentliche Upgrade erfolgt über das Skript catupgrd.sql. Sie finden dieses Skript im Verzeichnis $ORACLE_HOME/rdbms/admin.

Nach Abschluss des Upgrade-Skripts wird die Datenbank automatisch heruntergefahren. Sie müssen Sie anschließend mit dem Befehl startup bzw. startup normal starten.

Achtung: Sofern irgendwelche Fehler während der Ausführung von catupgrd.sql aufgetreten sind, können Sie die Ausführung jederzeit wiederholen. Oft ist die Fehlerursache ein zu kleiner Arbeitsspeicher oder nicht ausreichender Platz im System-Tabelspace. Be-heben Sie einfach das Problem, und rufen Sie anschließend das Upgrade-Skript er-neut auf.

Nach dem  erfolgreichen und fehlerfreien Abschluss des Upgrade-Skripts sollten invalide Objekte rekompiliert werden. Rufen Sie dazu das Skript utlrp.sql auf.

Sollte das Rekompilieren etwas länger dauern, können Sie mit folgender Abfrage das der-zeitige Geschehen prüfen:

Die Anzahl kompilierter Objekte sollte langsam steigen. Ob nach Abschluss der Rekompi-lierung Objekte verbleiben, die invalide sind, kann mit der View dba_objects überprüft werden. Alle Objekte, deren Wert in der Spalte status nicht „valid“ ist, sollten genau untersucht und nach einer Fehlerbehebung erneut rekompiliert werden. Die Gesamtzahl aller invaliden Objekte zeigt das folgende Skript:

Besitzer, Objekttyp und Namen der einzelnen nicht validen Objekte gibt das folgende Skript aus:

Der Status der einzelnen Datenbank-Komponenten lässt sich  über die View dba_registry überprüfen.

Sie sollten alle valide sein.

Post-Upgrade-Skript

Sie möchten wissen, ob Ihr Upgrade erfolgreich war? Das Skript utlu111s.sql gibt hierüber Auskunft:

Eine Ausgabe wie die folgende ist problematisch :