Ein Wegweiser für Oracle-Datenbank-Upgrades und Migrationen aller Art

Auf sicheren Pfaden
Kommentare

Für die meisten Datenbankumgebungen steht irgendwann ein Upgrade oder eine Migration an, sei es aus Supportgründen der Umstieg auf eine neue Datenbankversion, oder auch ein Wechsel des Servers, Betriebssystems, Storage oder Datenbankzeichensatzes bis hin zum Umzug in ein anderes Rechenzentrum. In diesem Artikel werden verschiedene Migrationspfade für Oracle-Datenbanken vorgestellt und jeweils mit ihren Möglichkeiten und Grenzen diskutiert.

Zunächst die Frage, warum migrieren wir überhaupt? Häufigster Grund für eine Migration ist natürlich die Supportsituation. Datenbanken älterer Versionsstände fallen irgendwann aus dem Oracle- oder Anwendungssupport heraus. Somit steht ein Versionsupgrade an. Aber auch die Nutzung neuer Datenbankfunktionen kann die treibende Kraft für einen Versionssprung sein. Häufig ist es auch eine Überlegung wert, eine ohnehin anstehende Migration mit einer Reorganisation zu kombinieren, um neue Techniken wie Securefile-LOBs zu nutzen, große Tabellen zu partitionieren, transparente Datenverschlüsselung einzuführen etc.
Ein Plattform- (Hardware-) bzw. Betriebssystemwechsel kann aus verschiedenen Gründen notwendig sein, beispielsweise um Kostensenkungen zu realisieren (Umstieg auf Linux) oder weil durch eine Unternehmensfusion eine neue strategische Plattform gesetzt ist. Durch Unternehmenszusammenschlüsse, Konsolidierungen, aber auch durch Outsourcing der IT oder ein Wechsel des Hosting-Providers ergeben sich oftmals Standortwechsel auch für das Datacenter. Der neue Provider hat womöglich eine andere „favorisierte“ Plattform, sodass eine Vielzahl kombinierter Standort- und Plattformmigrationen ins Haus steht. Auch ein Wechsel der Storage-Plattform, z. B. auf Oracle ASM, ist häufig aus Kosten- und Performancegründen motiviert.
Schließlich kann es im Rahmen einer fortschreitenden Globalisierung des Geschäfts notwendig sein, dass die Datenbank Unicode-fähig gemacht wird, um beispielsweise Zeichen aus dem ostasiatischen Raum überhaupt speichern und verarbeiten zu können. Ein solcher Zeichensatzwechsel kommt in den allermeisten Fällen einer Migration gleich.

Migrationsaspekte

Für die Durchführung der Migration steht eine ganze Reihe von Techniken zur Verfügung. Wegweisend sind einige Faktoren, die sich primär aus dem Umfang der Migration und der Kritikalität der Datenbank bzw. der darauf laufenden Anwendungen ergeben:

  1. Welches Migrationsszenario liegt vor: Wechsel von Datenbankversion, Edition, Plattform, Betriebssystem, Storage-Plattform, Standort oder Zeichensatz, Reorganisation von Teilen der Datenbank oder eine Kombination hiervon?

  2. Welche Auszeit ist erträglich? Natürlich ist eine geringstmögliche Auszeit immer erstrebenswert, andererseits aber regelmäßig auch die teuerste Lösung.

  3. Wie hoch ist der potenzielle Schaden im Fall eines Fehlschlags, und was passiert bei einem Fehlschlag? Eng damit verzahnt ist die Möglichkeit, im Vorfeld der Migration realistische

  4. Welcher Gesamtaufwand ist akzeptabel? Dies betrifft insbesondere Komplexität und Zeitaufwand der Migration sowie die Frage, ob die Migration „In-Place“ stattfindet oder „Out-of-Place“. Im letzteren Fall werden temporär Alt- und Neu-Datenbank parallel betrieben, sodass vorübergehend der doppelte Hardware- und Storage-Bedarf besteht

  5. Welcher Gesamtaufwand ist akzeptabel? Dies betrifft insbesondere Komplexität und Zeitaufwand der Migration sowie die Frage, ob die Migration „In-Place“ stattfindet oder „Out-of-Place“. Im letzteren Fall werden temporär Alt- und Neu-Datenbank parallel betrieben, sodass vorübergehend der doppelte Hardware- und Storage-Bedarf besteht.

In den folgenden Abschnitten werden nun verschiedene Migrationstechnologien vorgestellt. Dabei wird jeweils skizziert, für welche Migrationsszenarios diese Technologie in Frage kommt und welche Vor- und Nachteile sie mit sich bringt.

Das gute, alte Standardupgrade

Mit dem Database Upgrade Assistant (DBUA), der mit der Datenbanksoftware installiert wird, kann sehr bequem ein Versionsupgrade bestehender Datenbanken durchgeführt werden. Der DBUA prüft vor der Migration automatisch alle erforderlichen Voraussetzungen.

Abb. 1: Mögliche Upgradepfade beim Standardupgrade mit dem Oracle DBUA

In jedem Fall handelt es sich um ein reines Versionsupgrade, seit 11g optional kombiniert mit einer Storage-Migration. Außerdem ist ein Wechsel von 32 Bit Oracle Software auf 64 Bit Software möglich. Im Zuge des Upgrades können aber weder Server-, Plattform- oder Zeichensatzwechsel noch Reorganisationen der Datenbank durchgeführt werden. Die konkrete Upgradezeit und damit Auszeit hängt von den installierten Datenbankoptionen und -komponenten ab. Typische Zeiten liegen zwischen 30 und 90 Minuten. Je weniger Optionen installiert sind (Text-, Spatial-Option, JVM, XML DB etc.), desto schneller das Upgrade. Es handelt sich um ein In-Place-Upgrade, daher ist die einzige Rückfallmöglichkeit das in [1] beschriebene manuelle Downgrade, für das eine ähnliche Auszeit wie das eigentliche Upgrade veranschlagt werden kann. Vor dem Beginn des Upgrades sollte man sich schließlich noch vergewissern, dass der geplante Versionssprung überhaupt möglich bzw. unterstützt ist, ob ggf. vorher ein Patch-Release eingespielt oder sogar ein Upgrade in zwei Schritten durchgeführt werden muss. Abbildung 1 zeigt die möglichen Schritte, im Zweifelsfall sollte man die offizielle Dokumentation [1] der neuen Datenbankversion zu Rate ziehen, in der alle unterstützten Versionssprünge beschrieben sind.
Im Vorfeld wird die neue Datenbanksoftware installiert und ggf. gepatcht. Nach dem Aufruf des DBUA der neuen Softwareversion ist der Ablauf Wizard-gesteuert und in weiten Teilen selbsterklärend bzw. in [2] beschrieben. Für umfangreiche Umgebungen bietet der DBUA auch ein Silent Upgrade. Nach erfolgtem Upgrade ist der Serverparameter compatible der Datenbank noch auf den alten Versionsstand gesetzt. Die neue Datenbank nutzt also noch keine neuen Features. Der Pferdefuß dieser Methode ist, dass ein Rückfall auf die alte Version (Downgrade) auch nur möglich ist, solange dieser alte compatible-Wert gesetzt ist. Probleme nach dem Upgrade zeigen sich häufig aber erst nach dem Heraufsetzen des compatible-Werts. Das Heraufsetzen ist jedoch eine Einbahnstraße und macht ein nachfolgendes Heruntersetzen oder Downgrade unmöglich.

Aufmacherbild: Pathway through the rolling grassy hills von Shutterstock / Urheberrecht: Cardens Design

[ header = Ein Verschiebe-Bahnhof für die Daten ]

Ein Verschiebe-Bahnhof für die Daten

Die Werkzeuge exp/imp erlauben eine Übertragung auch von älteren Datenbankversionen. Insbesondere für diesen Zweck ist ihre Nutzung auch vollständig unterstützt. Für die Migration neuerer Datenbankversionen – ab der Version 10g – sollte allerdings die Alternative Data Pump in Betracht gezogen werden. Ab der Version 11g wird die Benutzung von exp nicht mehr unterstützt, imp hingegen schon.
exp/imp sind durch ihre lange Historie sehr zuverlässig, haben allerdings gegenüber Data Pump Performancedefizite. Mit beiden Tools sind zusätzlich auch beliebige Plattform-, Storage- oder Zeichensatzwechsel und auch Reorganisationen möglich.
Nachteilig sind in jedem Fall die langen Übertragungszeiten und damit Auszeiten proportional zur Datenmenge. Beide Tools sind insbesondere für LOB-Spalten sehr langsam. Der Import läuft jeweils etwa zwei- bis dreimal so lange wie der Export. Bei Datenbanken im TB-Bereich landet man so schnell bei Auszeiten im Bereich mehrerer Tage. Ein Fallback nach bereits erfolgten Datenänderungen auf der neuen Datenbank dauert nochmals etwa genauso lang.
Das benutzte Exportwerkzeug muss der Version der alten Datenbank entsprechen. Analog muss das benutzte Importwerkzeug der Version der neuen Datenbank entsprechen. Der Hintergrund ist, dass zwar das von exp/imp bzw. Data Pump benutzte Dateiformat abwärtskompatibel ist, nicht aber die Werkzeuge selbst. Häufig ist es sinnvoll, einfach das jeweilige Werkzeug aus dem entsprechenden Oracle-Home des Datenbankservers aufzurufen. Auf diese Weise muss auch nicht die gesamte Datenbank über das Netzwerk übertragen werden, sondern wird lokal auf dem Datenbankserver exportiert bzw. importiert. Für das Übertragen der Strukturen bzw. Daten sollte entweder mit dem Benutzer SYSTEM (nicht mit SYS, sonst würde das Data Dictionary mit exportiert) ein Full-Export (Option FULL=Y) oder ein expliziter Export der einschlägigen Schemata oder sogar Tabellen angestoßen werden.
Export, Übertragung der Daten und Import können parallelisiert werden, wobei gleichzeitig das Disk-I/O zum Schreiben und Lesen der Dump-Dateien wegfällt. Bei exp/imp geht dies auf Unix-/Linux-Systemen, indem jeweils eine Named Pipe als Zieldatei angegeben wird und ein weiterer Prozess per SSH die Daten aus der einen Named Pipe in die andere schreibt. Bei Data Pump gibt es hierfür einen eigenen Parameter namens NETWORK_LINK. Vor einer Datenübertragung mit Data Pump zwischen Datenbanken mit unterschiedlichen Zeichensätzen sollte man unbedingt [3] zu Rate ziehen, da es bei älteren Patch-Levels sonst zu Datenkorruptionen kommen kann.

TTS und TDB – Daten im Expressversand

Ursprünglich aus dem Data-Warehouse-Bereich stammend bietet die so genannte „Transportable Tablespace (TTS)“-Technik auch einen Migrationspfad. Seit der Version 10gR1 ist hiermit das server-, plattform- und storageübergreifende Kopieren von Tablespaces möglich, wobei das Oracle-Backup-Werkzeug RMAN die Konvertierung übernimmt. Mit „Transportable Database (TDB)“ geht dies ab der Version 10gR2 auch für die internen Tablespaces SYSTEM und SYSAUX, allerdings nur für Plattformwechsel innerhalb derselben Endianness-Gruppe. So ist mit TDB z. B. ein Wechsel zwischen Linux und Windows möglich (Little-Endian), oder auch ein Wechsel zwischen AIX und HP-UX (Big-Endian), nicht aber zwischen AIX und Linux.
Jede Datenbank listet in der View V$TRANSPORTABLE_PLATFORM alle für TTS in Frage kommenden Zielplattformen auf (dies sind nahezu alle Oracle-Plattformen), in der View V$DB_TRANSPORTABLE_PLATFORM alle für TDB unterstützten Zielplattformen, sprich alle Plattformen mit derselben Endianness. In jedem Fall muss zumindest die Quelldatenbank als Enterprise Edition lizenziert sein. Da es sich letztlich um das Erstellen einer physischen Kopie der bestehenden Datenbank nebst Konvertierung auf eine andere Plattform handelt, sind mit dieser Methode weder Versionssprünge noch Zeichensatzmigrationen oder Reorganisationen möglich. Für
die Dauer der Übertragung ist die alte Datenbank Read-Only. Die Auszeit ist also proportional zur Datenbankgröße, aber deutlich geringer als bei der Export-/Import-Methode. Beide Methoden sind im Detail unter [4] beschrieben. Abbildung 2 stellt den Ablauf stark vereinfacht dar.

Abb. 2: Migration mit Transportable Tablespace oder Transportable Database

Ein Trick mit ASM

Läuft die Datenbank bereits auf Basis von Oracle ASM (Automatic Storage Management) und möchte man lediglich auf einen anderen Storage-Hersteller, Storage-Turm und/oder andere Platten migrieren, lassen sich sehr geschickt die Rebalancing-Fähigkeiten von ASM ausnutzen [5]. Bei dieser Methodik entsteht keine Auszeit im eigentlichen Sinn, sondern lediglich zwischenzeitlich eine erhöhte I/O-Last auf dem Datenbank-Storage. Nach Bereitstellung und Stamping der neuen Platten auf dem Datenbankserver fügt man für jede ASM-Diskgruppe zuerst alle neuen Platten der Disk-Gruppe hinzu und entfernt anschließend alle alten Platten. Das automatische Rebalancing sorgt nun für eine entsprechende Neuverteilung der Daten. Mit der View V$ASM_OPERATION in der ASM-Instanz lässt sich überprüfen, ob bzw. wann das Rebalancing voraussichtlich beendet ist. Anschließend kann man die alten Platten abhängen.

Rollierende Upgrades

Seit der Version 10.1.0.3 ist ein so genanntes „Rolling Upgrade“ der Datenbank möglich, mit dem sich Auszeiten im Minutenbereich realisieren lassen. Außerdem verringert sich das Risiko durch menschliche oder andere unerwartete Fehler beim Upgradeprozess. Diese Vorteile werden mit einer deutlich höheren Gesamtkomplexität des Upgradeprozesses erkauft. Hat man die entsprechende Infrastruktur in Form einer Logical Standbydatenbank erst einmal aufgebaut, lässt sich diese aber auch für zukünftige Upgrades wiederverwenden. Es handelt sich um ein Out-of-Place-Upgrade, d. h. es wird eine neue Datenbank parallel zur bestehenden aufgebaut. Außer dem Versionssprung ist auch ein optionaler Storage-Wechsel möglich, nicht hingegen Reorganisationen, Plattform- oder Zeichensatzwechsel. Sollten nach dem Upgrade Probleme auf der neuen Datenbank auftreten, kann ohne Datenverlust wieder auf die alte Umgebung zurückgefallen werden, wobei dafür in der Praxis zumeist ein manuelles Versions-Downgrade durchgeführt werden muss, das entsprechend vorher getestet werden sollte und etwa eine Stunde dauert.
Das gesamte Verfahren ist nur im Rahmen der Oracle Enterprise Edition nutzbar. Tabellen mit benutzerdefinierten Datentypen (Objekttypen, VArrays und Nested Tables) sind erst seit Oracle 10gR2 und nur mit erheblichem manuellem Zusatzaufwand verarbeitbar. Dazu gehören auch diverse Datentypen, die von der Spatial-, Image- oder Textoption verwendet werden. Einen umfassenden Überblick über nicht unterstützte Objekte einer Datenbank gibt die Oracle-View DBA_LOGSTDBY_UNSUPPORTED. Das Verfahren sieht grob skizziert so aus:

  1. Von der bestehenden Datenbank (Primärdatenbank) wird zunächst auf einem anderen Server eine Physical Standbydatenbank aufgebaut, die anschließend in eine Logical-Standbydatenbank umgewandelt wird. Damit hat man eine Replikation von der bestehenden Datenbank auf die Standbydatenbank aufgesetzt.

  2. Nun wird ein normales Versionsupgrade der Standbydatenbank mittels DBUA durchgeführt.

  3. Anschließend werden die Anwendungen gestoppt und alle Verbindungen auf die bisherige Datenbank beendet. Hier beginnt die kurze Auszeit.

  4. Mit einem so genannten „Graceful Switchover“ tauschen Primär- und Standbydatenbank ihre Rollen. Änderungen auf der neuen Datenbank werden nun auf die alte Datenbank zurückrepliziert.

  5. Die Anwendungen werden gegen die neue Datenbank gestartet. Damit ist die Auszeit beendet.

  6. Optional kann man nun ein Versionsupgrade (wiederum mit dem DBUA) der alten Datenbank durchführen und die Anwendungen nach einem erneuten Rollentausch auf diese zurückschwenken, wodurch aber eine zweite kurze Auszeit anfällt.

Die genaue Durchführung umfasst je nach Umgebung einige bis einige Dutzend Schritte und ist sehr detailliert in [4] beschrieben.

[ header = Rollierende Migrationen ]

Rollierende Migrationen

Alternativ zu den bisher beschriebenen Verfahren gibt es noch den Weg über eigenständige Replikationswerkzeuge wie Quest Software SharePlex, Oracle Goldengate oder IBM InfoSphere CDC [6], [7], [8]. Während SharePlex sich auf die Oracle-Welt spezialisiert hat und dort eine sehr umfangreiche Featureabdeckung bietet, haben die anderen beiden Lösungen einen heterogenen Ansatz, unterstützen also auch Datenbanken wie SQL-Server, DB2, Sybase, Teradata etc. Diese „Rolling Migrations“ haben große Ähnlichkeit mit dem zuvor beschriebenen „Rolling Upgrade“. Die zusätzlich anfallenden Lizenzkosten werden mit zwei entscheidenden Vorteilen aufgewogen:

  1. Die neue Datenbank muss kein physischer Klon der bestehenden Datenbank sein, sondern kann mittels Datenexport/-import aufgebaut werden. Dadurch behält man die Vorteile eines „Rolling Upgrade“ und bekommt zusätzlich die Möglichkeit beliebiger Plattformsprünge, Zeichensatzänderungen oder Reorganisationen. Außerdem ist man unabhängig von Version und Edition der beteiligten Datenbanken.

  2. Die erwähnten Werkzeuge leisten eine Replikation, bei der aus den Redolog-Dateien der bestehenden Datenbank die SQL-Kommandos und Transaktionen rekonstruiert und anschließend auf der neuen Datenbank ausgeführt werden. Dies ist entscheidend, da die SQL-Syntax im Gegensatz zum Redolog-Format unabhängig von Quell- und Zielumgebung ist.

Abb. 3: Ablauf einer Rolling Migration

Abbildung 3 zeigt den groben Ablauf. Die neue Datenbank wird zunächst als leere Datenbank, z. B. mit dem Database Configuration Assistant (DBCA) angelegt. Anschließend wird die Replikation von der bestehenden in die neue Datenbank gestartet und sofort gepuffert, da die Zieldatenbank noch leer ist (Schritt 1). Nun überträgt man einen konsistenten Datenbestand, indem z. B. die Werkzeuge exp bzw. Data-Pump-Export mit dem Parameter FLASHBACK_SCN aufgerufen werden. Nach dem Import müssen bestimmte Datenbankobjekte wie Trigger oder Jobs auf der neuen Datenbank zunächst deaktiviert werden, damit replizierte Änderungen nicht doppelt ankommen. Die Replikation synchronisiert sich anschließend mit der benutzten SCN und fährt alle während der Initialbefüllung gepufferten Änderungen nach (Schritt 2). Bis hierhin ist keinerlei Auszeit aufgetreten.
Der Rest ist analog zu den Rolling Upgrades, d. h. die Benutzer und Anwendungen werden auf die neue Datenbank geleitet. Zuvor aktiviert man Trigger und Datenbankjobs auf der neuen Datenbank, deaktiviert sie auf der alten Datenbank und dreht die Replikationsrichtung, um sich eine Fallback-Möglichkeit auch nach Tagen ohne Datenverlust zu sichern (Schritt 3).

Anwendungstests

Replikationsbasierte Methoden wie Rolling Upgrades oder Rolling Migrationen bieten auch die Möglichkeit umfangreicher Applikationstests (sowohl funktionale als auch Performancetests) mit realistischen Daten, bevor man auf die neue Datenbank umschaltet. Am einfachsten ist es, wenn die Zieldatenbank mindestens den Versionsstand 10g hat und als Enterprise Edition lizenziert ist. Dann lässt sich die „Flashback Database“-Funktion nutzen. Ist dies nicht der Fall, muss man stattdessen mit normalen Datenbank-Backups arbeiten. Vorbereitend aktiviert man die Flashback-Database-Funktion in der neuen Datenbank (die noch nicht produktiv ist):

SQL> STARTUP MOUNT
SQL> ALTER SYSTEM SET db_flashback_retention_target=1440;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE FLASHBACK ON;
SQL> ALTER DATABASE OPEN;

Für einen Testlauf wird nun die Replikation gepuffert und ein Snapshot erstellt, der bei Oracle „Restore Point“ heißt (ist die Datenbank nicht als Enterprise Edition lizenziert, führt man alternativ ein Cold Backup durch): SQL> CREATE RESTORE POINT xyz;.

Nun kann man beliebige Testläufe durchführen. Anschließend setzt man die Datenbank einfach auf den Restore-Point zurück (alternativ spielt man das zuvor erstellte Backup wieder ein):

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT
SQL> FLASHBACK DATABASE TO RESTORE POINT xyz;
SQL> ALTER DATABASE OPEN RESETLOGS;

Danach startet man die Replikation wieder, wodurch auch die gepufferten Änderungen nachgefahren werden.

Fazit

Viele Wege führen zum Ziel, es kommt ganz auf die Rahmenbedingungen der Migration an. Neben einer Reihe nativer Werkzeuge und Techniken gibt es auch einige Produkte von Drittherstellern. Tabelle 1 gibt einen Gesamtüberblick der besprochenen Methoden mit ihren jeweiligen Möglichkeiten und Grenzen. Mit der passenden Methode können auch komplexe Umstellungen in einem einzigen Schritt absolviert werden.
Der Autor kann aber aus eigener Erfahrung sagen, dass jede Migration einer geschäftskritischen Datenbank ein Projekt darstellt und dass auch bei genauer Planung so gut wie immer unvorhergesehene Dinge passieren. Geeignete Testläufe (sowohl funktionale als auch Performancetests) mit realistischen Daten und auch einer realistischen Last sind daher – zumindest für kritische Datenbanken – dringend zu empfehlen.
Replikationsbasierte Methoden wie Rolling Upgrades oder Rolling Migrations leisten dies, indem z. B. die Flashback-Database-Funktion der Datenbank genutzt wird. Letztlich bieten diese Methoden eine geringere Auszeit sowie ein geringeres Risiko für den Preis eines insgesamt höheren Projekt- und Umsetzungsaufwands.

Tabelle 1: Migrationsmethoden im Vergleich (ZS: Zeichensatzmigration, FB v/n: Fallback vor/nach der Umstellung, Kompl.: Komplexität des Migrationsprozesses)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -