Gedanken zum Thema „Datenbank-Migration“

Im letzten Jahr war ich auf der DOAG-Konferenz bei einer Panel-Diskussion zum Thema „Datenbank-Migration“ dabei.
Natürlich ging es da auch um die High-End-Fälle, in denen man PetaByte-Datenbanken nur mit dem undokumentierten ParameterX und dem Spezialtool Y in der geforderten Zeit mit minimaler Downtime von Plattform A nach Plattform B migrieren konnte. Natürlich sind solche Fälle interessant und man kann einiges daraus lernen. Aber das ist sicher nicht der Alltag. Darum hier meine Gedanken zu den eher alltäglicheren Datenbank-Migrationen.

Aufräumen

Eine Datenbank-Migration ist immer eine gute Gelegenheit, in der Datenbank aufzuräumen. Braucht man die Tabelle KUNDEN_BACKUP_20210813 wirklich noch? Und was ist mit den Tabellen KLAUS01 und GERD02?
Und manchmal entdeckt man auch ein Applikationsschema von einer Applikation, die schon lange nicht mehr im Unternehmen verwendet wird. Bei einem Kunden hat ein Kunden-DBA vor einer Migration mal ein derartiges Schema mit etwa 300 GB entdeckt. Das war bei einer Gesamtgröße der Datenbank von 500 GB doch ein wesentlicher Teil und mit der reduzierten Datenmenge waren die geforderten Vorgaben für die maximale Auszeit erreichbar.

Ungültige Datenbank-Objekte

Ein aus meiner Sicht sehr guter Kandidat für das Aufräumen in der Datenbank sind ungültige Objekte:

set linesize 120
column owner format a30
column object_type format a20
column object_name format a40

select owner,object_type,object_name from dba_invalid_objects
order by owner,object_type,object_name;

Ich habe zu ungültigen Objekten eine ganz klare Meinung:
ungültige Objekte haben in einer Produktionsdatenbank nichts zu suchen!
Denn wenn der Standard „0 ungültige Objekte“ ist, dann erkennt man in „1 ungültiges Objekt“ direkt ein mögliches Problem. Bei „123 ungültigen Objekten“ anstelle von vorher „121“ kann er schon schwerer werden, darin ein Problem zu erkennen.

Bevor man diese ungültigen Objekte löscht, sollte man zumindest einmal versuchen, sie neu zu kompilieren:

@?/rdbms/admin/utlrp.sql

Das, was dann noch übrig bleibt, kann man – meiner persönlichen Meinung nach – grundsätzlich löschen. Wenn man diese Objekte aber – sicher ist sicher – doch behalten möchte, dann sollte man sich vor Beginn der Migration die Liste der ungültigen Objekte abspeichern und nach der Migration mit der Liste der ungültigen Objekte vergleichen. Wenn es die gleichen sind, dann ist „OK“, wenn es mehr sind, muss man in die Fehlersuche investieren. Ggf. fehlt in der neuen Datenbank ein DBMS-Package oder ein direkter Grant eines SYS-Objektes, oder, oder, oder.

Auszeit vs. Datenmenge

Ein aus meiner Sicht wesentliches Kriterium für die Wahl der Migrationsmethode ist das Verhältnis zwischen Datenmenge und maximal möglicher Auszeit. Platt formuliert: bei einer 200 GB-Datenbank, bei der ich Freitag Nachmittag um 15 Uhr die Applikation runterfahren kann um sie dann am Montag morgen um 7 Uhr mit der neuen Datenbank wieder zu starten, nehme ich DataPump. Bei der 10 TB-Datenbank im 24×7-Betrieb, bei der ich einmal im Jahr eine 4-Stunden-Auszeit an einem Sonntag zwischen 2 und 6 Uhr bekommen kann, muss ich eine andere Methode wählen.

DataPump ist dein Freund

Ich bin ein Freund davon, wenn immer möglich, Datenbank-Migrationen mit DataPump durchzuführen. Dafür gibt es viele Gründe:

• die Quell-Datenbank bleibt als Rückfall-Lösung erhalten
• die Ziel-Datenbank ist reorganisiert
• DataPump ermöglicht einen einfachen Plattform-Wechsel und auch einen Zeichensatz-Wechsel Richtung Unicode (in diesem Fall aber bitte vorher die „Length-Semantics“ der VARCHAR2-Spalten etc. der Quell-Datenbank auf „CHAR“ ändern, damit erspart man sich einige Probleme)
• Man kann Teile der Datenbank migrieren (z.B. wenn die Datenbank die Daten von mehreren Applikationen enthält (idealerweise in verschiedenen Schematas) und man die Applikationen zu unterschiedlichen Zeitpunkten migrieren möchte oder muss

Natürlich hat DataPump auch Nachteile:

• es wird Platz für die Dump-Datei benötigt (es sei denn man holt sich von der Ziel-Datenbank die Daten via Datenbank-Link aus der Quell-Datenbank)
• „DataPump ist langsam“ – grundsätzlich ja, aber es gibt viele Tuning-Möglichkeiten (vorher Datenbank-Statistiken in der Quelle aktualisieren, Statistiken nicht mit exportieren, DataPump parallelisieren (Enterprise Edition), vorher DataPump-Bundle-Patch installieren etc.)

Grundsätzlich ist DataPump aber ein bewährtes und stabiles Werkzeug für Datenbank-Migrationen.

Automatisieren

Egal, welches Werkzeug man für eine Datenbank-Migration nimmt, es gibt immer weitere Vor- oder Nachbereitungsschritte. Und alle Schritte einer Migration sollte man soweit wie möglich automatisieren: das vorherige Anlegen der Tablespaces im Zielsystemen, Deaktivieren des Monitorings für das Quellsystem, Durchstarten der Quelldatenbank im „RESTRICTED“-Modus, damit man vor dem DataPump-Export eine „saubere“ Datenbank ohne Applikationsbenutzer hat usw.
Die genauen Schritte unterscheiden sich zwar sicher nach gewählter Migrationsmethode, aber alles, was ich bei einer Migration mit getesteten (!) Skripten machen kann, verhindert Fehler bei der Migration.

Runbook

Eng verbunden mit dem Thema „Automatisierung“ ist das Thema „Runbook“: wer macht was in welcher Reihenfolge? Wie lange dauern die Schritte aufgrund der Erfahrungen in den Tests in etwa? Was kann parallel erfolgen? Welche Schritte müssen erledigt sein, bevor Schritt X gestartet werden kann und was sind die nächsten Schritte nach Schritt X? Wer muss nach Schritt Y informiert werden?
Und das sind nur die wichtigsten Schritte.
So ein Runbook wächst mit der Erfahrung und ist besondere dann hilfreich, wenn viele Menschen bei einer Migration mitarbeiten. Und dann weiß der Netzwerk-Admin auch, dass er – gemäß Migrationsplan (Runbook) – gegen 23:30 Uhr die Information bekommen soll, dass er einen DNS-Eintrag ändern soll, dann kann er sich darauf vorbereiten.
Aber auch wenn ich als einsamer DBA ganz alleine eine Migration mache, habe ich mir angewöhnt, immer mit solchen „Runbooks“ zu arbeiten. Ansonsten geschieht es zu schnell, dass man in der Hektik des Geschehens vielleicht einen Schritt vergißt.
Außerdem ist es hilfreich, sich in so einem Runbook zusätzlich zu den geplanten Zeiten für die einzelnen Schritte auch die realen Laufzeiten zu protokollieren. Damit wird das Runbook zu einem „Migrationsprotokoll“ und die reale Dauer der einzelnen Schritte ist ein wertvolles Hilfsmittel um das Runbook für die nächste Migration zu verfeinern.

Point-of-no-Return und die Fallback-Lösung

Trotz aller Tests im Vorfeld kann am Tag X immer was schiefgehen: der gescheiterte Datentransfer auf das Zielsystem, weil die Netzwerkverbindung kurzzeitig mal weg war, der gescheiterte Backup (den man als sorgfältiger DBA im Vorfeld immer macht), weil doch nicht genug Platz auf der Backup-Platte war. Murphy ist bei der jeder Migration mit dabei und verzögert den Zeitplan. Und solche Verzögerungen können dazu führen, dass man in der verbleibenden Rest-Auszeit die Migration nicht mehr schafft. Also: Kommando zurück, alles wieder in den alten Zustand zurückbringen – und auch für diese Fallback-Lösung muss es ein (getestes) Runbook geben. Oder wenn man nach einer vermeintlich erfolgreichen Migration doch Probleme mit der Applikation hat.
Und auch der „Point-of-No-Return“ muss festgelegt werden. Oftmals ist es der erste Start der Applikation mit der neuen Datenbank, nach dem es keinen Weg mehr zurück gibt. Und wenn man diesen Punkt überschritten ist, dann geht der Weg nur nach vorne. Und wenn es Probleme gibt, dann muss man wissen, wenn man ansprechen kann: welcher Kollege aus dem Storage-Bereich ist erreichbar? Welcher Netzwerker hat Rufbereitschaft? usw. Aber auch: wer ist die Eskalationsinstanz im Management, wenn es massive Probleme gibt, die z.B. den rechtzeitigen Start einer kritischen Applikation gefährden? Und: wie sieht es mit Hersteller-Support aus? Einmal hat einer meiner Kunden eine längerfristig geplante Migration eines kritischen Systems absagen müssen, weil Oracle für den gleichen Termin eine Auszeit für das Support-Portal „My Oracle Support“ angekündigt hat.

Datenqualität

„Datenqualität“ ist ein Thema, das eher bei Migrationen von einem Datenbank-System in ein anderes interessant ist, z.B. bei einer Migration von Oracle nach PostgreSQL: wie stelle ich sicher (und wie prüfe ich), dass die Daten korrekt im Zielsystem angekommen sind: das betrifft zum einen Sonderzeichen wie z.B. Umlaute, die dann bitte auch in der Zieldatenbank korrekt ankommen sollte. Allerdings sind alphanumerische Daten meist das geringere Problem. Spannender sind meiner Erfahrung nach numerische Werte, die über die in den meisten Fällen genutzte Genauigkeit von 2 – 3 Nachkommastellen hinausgehen. Aufgrund der unterschiedlichen Datentypen in den verschiedenen Datenbanken und der unterschiedlichen Art und Weise, wie Daten intern gespeichert werden, kann es da auf den „hinteren Nachkommastellen“ durchaus mal zu Abweichungen kommen.

Applikationsknowhow dabei

In solchen Fällen ist es sehr hilfreich, wenn man jemanden mit tiefem Applikationsknowhow dabei hat. Für den DBA oder für den externen Berater sind es praktisch nur abstrakte Daten und die wirkliche Bedeutung kann man oft nicht abschätzen. Aber auch in anderen Fällen kann Applikationsknowhow sehr hilfreich sein. Auch dazu ein Beispiel aus meinem Beraterleben: 6 TB-Datenbank, mehr als 30.000 Objekte in der Datenbank, Migration von HP-UX nach Linux, Wechsel von Oracle 9i nach 10g maximale Auszeit 6 Stunden. Bei diesem Rahmenbedingungen wird es für generische Methoden anspruchsvoll bis unmöglich. Die Lösung kam dann von einem Applikationsentwickler: die Datenbank enthielt sehr viele nach Datum bzw. Uhrzeit partitionierte Tabellen. Und dem Entwickler war bekannt, dass – hier kommt das Wissen rund um die Applikation ins Spiel – Daten zwar nachträglich geändert werden konnten, dass die aber für Daten, die älter als eine Woche waren, nicht mehr erfolgte. Die Lösung war dann einfach: Alles das, was älter als eine Woche war, wurde im Vorfeld der Migration übertragen, so dass zum Migrationstermin nur noch „eine Woche an Daten“ transferiert werden musste. Damit war die Datenmenge klein genug für das Auszeitfenster – und die Migration war gerettet.

Testen, Testen, Testen – hoffentlich automatisiert

Egal welche Methode man für eine Migration wählt, jede Migration sollte vorher getestet werden – und das hoffentlich automatisiert: so findet man Fehler in den Skripten, den ein oder anderen Schritt den man dann doch im Runbook vergessen hat oder wo man das Runbook noch verfeinern muss, eine Fehlersituation, die man in den Skripten noch abfangen sollte, usw.. Und man bekommt auch wichtige Informationen zur Dauer der Migration und ob das Ziel der „maximalen möglichen Auszeit“ erreichbar ist.

Irgendeinen Preis zahlt man immer

Jede Migration hat ihren Preis: DataPump ist einfach und stabil – dauert aber. Und wenn ich eine Migration mit „minimaler Downtime“ haben will, dann muss ich komplexere Methoden nutzen, die ich testen muss usw. – da steckt der Preis in dem Vorbereitungsaufwand. Und es kann durchaus vorkommen, dass man zu dem Schluss kommt: der Vorbereitungsaufwand für die neue Methode X wird uns zu hoch, wir migrieren mit der bewährten Methode Y – und zahlen den Preis einer längeren Auszeit.

In diesem Sinne: erfolgreiches Migrieren!

Foto von Egor Ivlev auf Unsplash