Sehen wir uns ein Beispiel an: Wir haben eine Anwendung, die in einer Oracle Datenbank betrieben wird und deren Daten in eine PostgreSQL-Datenbank migriert werden sollen. Die Datenbank wurde mittels ora2pg in ein Schema „Staging“ in PostgreSQL migriert. Dieses Schema halten wir dabei in derselben Datenbank wie das spätere Zielschema.

Warum wählen wir diesen Ansatz?

Der Ansatz hilft uns, einfache SQL-Abfragen für die Migration zu nutzen. Alternativ kann es sinnvoll sein, das Staging-Schema in einer eigenen Datenbank, bzw. Datenbankcluster zu halten, um die Datenbanken zu entkoppeln. Dazu können wir Postgres Foreign Data Wrapper nutzen, um genauso einfach auf die Daten zugreifen zu können. Dies kann wichtig sein, etwa um den zusätzlichen Speicher für das Staging Schema wieder freigeben zu können.

Bei vielen Cloud-Anbietern kann der einmal einer DB zugewiesene Speicher nicht wieder freigegeben werden. Liegt das Staging-Schema in einem eigenen Datenbankcluster, kann der gesamte Server einfach gelöscht werden.

Frühzeitig beginnen!

Wir halten es für sinnvoll, möglichst frühzeitig mit der Entwicklung der Migrationsskripte zu beginnen. Häufig stellen wir fest, dass die Altdaten Konstellationen enthalten, die man im zukünftigen Schema nicht mehr zulassen möchte. Dann stellt sich die Frage, wie mit den Altdaten umgegangen werden soll.

Tests mit realistischen Datenmengen

Migration und Re-Implementierung der Anwendung finden gleichzeitig statt. Dieser Umstand erweist sich als Glücksfall, denn die Migration sorgt so als Treiber für einen Datenbank-First-Ansatz. Für die Re-Implementierung ist es hilfreich, dass wir bereits mit den (anonymisierten) Altdaten arbeiten können. Dies liefert eine realistische Datenmenge, denn Abfragen auf leeren Tabellen sind ja immer schnell. Die Nutzung von Produktionsdaten zu Testzwecken ist dagegen ein anderes Thema.

Immer, wenn sich das Zielschema ändert, müssen die Daten-Migrationsskripte angepasst werden.
Was gehört zu einer performanten Migration?

Es gibt verschiedene Arten von Migrationen. In der Regel ist es sinnvoll, bei IT-Systemen eine inkrementelle Migrationsstrategie zu verfolgen. Das kann bedeuten, dass Teile des IT-Systems jeweils in einem Schritt migriert werden (Big Bang). Eine performante Migration der Daten ist dann wichtig.

Beim Bulk-Load von Daten in eine PostgreSQL-Datenbank oder zwischen Tabellen gibt es einiges zu beachten, um eine möglichst gute Performanz zu erzielen. Ähnliches gilt auch für andere Datenbanken.

Angelehnt an die Liste von EDB sind folgende Punkte wichtig für unser Szenario (PostgreSQL/PostgreSQL mittels SQL):

Im nächsten Schritt werden die Daten mittels SQL-Skripten geladen. Danach werden die Indizes, Constraints, Triggers und Foreign Keys wiederhergestellt. Zum Abschluss sollte ein analyze ausgeführt werden, um die Statistiken zu aktualisieren.

Wird die Anwendung neu entwickelt, so ändert sich das Zielschema. Dabei sind insbesondere die Änderungen an den Zieltabellen interessant in die hinein migriert wird. Typische Änderungen die Auswirkung auf die Migrationsskripte haben sind:

Es ist wichtig, dass diese Änderungen entweder automatisch erkannt und berücksichtigt werden oder vor Ausführung der Skripte auffallen. Da die Laufzeiten für die Migrationen sehr lang sein können (Stunden bis Tage), müssen Fehler möglichst früh erkannt werden. Sonst kann die (unbeobachtete) Probemigration erst nach vielen Stunden fehlschlagen und wird nicht abgeschlossen. Damit werden viele Stunden wertvoller Projektzeit verschwendet.

jOOQ generiert aus einem Datenbankschema ein Klassenmodell. Dieses beinhaltet Informationen über die gängigen Datenbankobjekte wie Tabellen, Spalten, Indizes, Constraints, Triggers und Foreign Keys. Mittels dieses Klassenmodells kann man dann einfach alle Indizes oder Constraints einer Tabelle entfernen oder neu erzeugen.

Das Beispielprojekt nutzt jOOQ, um die SQL-Migrationsskripte zu erzeugen, ohne die eigentliche Migration durchzuführen.

Wenn wir dabei alle Tabellen mittels eines topologischen Sortieralgorithmus sortieren, dann können wir die Tabellen in der richtigen Reihenfolge behandeln. Dies ist wichtig, damit wir Constraints in der richtigen Reihenfolge löschen und wiederherstellen. Dies gilt im Kontext dieses Blog-Post zumindest solange, wie der „Tabellengraph“ keine Zyklen enthält.

Wir nutzen die generierten SQL-Skripte für die Behandlung der Indexe und Constraints. Dadurch vergessen wir keine Objekte zu löschen oder zu erzeugen, die im Rahmen der Weiterentwicklung noch entstehen oder gelöscht werden.

Der Hintergrund für den Umweg über die SQL-Skripte ist, dass wir die Skripte auch in anderen Umgebungen ausführen können. Generell sollten die Aktionen nicht vom Notebook eines Entwicklers oder einer Entwicklerin ausgeführt werden, sondern von einem dedizierten Migrationssystem (virtuelle Maschine). Wenn ihr die Migration manuell startet, solltet ihr darauf achten, dass dies unter einem Terminal-Multiplexer wie tmux oder screen geschieht. Damit die Ausführung nicht abbricht, wenn der ausführende Benutzer die Verbindung beendet. Die Dauer der Migration hängt stark von der Größe der Datenbank ab. Selbst für einige kleine Datenbanken mit < 250 Mio Einträgen und mehreren Tabellen kann die Migration mehrere Stunden dauern. Bei größeren Migrationen ist sicherlich noch eine gesonderte Betrachtung notwendig, um Laufzeiten zu optimieren.

Ein weiterer Vorteil kann die Nachbearbeitung der Skripte sein. Etwa wenn ihr beim Umgang mit den Constraints leichte Anpassungen vornehmen müsst, weil die Datenbank doch Zyklen enthält.

Das Beispielprojekt ist auf GitHub verfügbar. Eine etwas ausführlichere Dokumentation findet sich auf den zugehörigen Github Pages.

Auch wenn Änderungen nicht erkannt werden, ist die Nutzung von jOOQ für die Erstellung von Migrationsskripten sehr hilfreich und kann einige Fehlerquellen adressieren, die bei gleichzeitiger Entwicklungstätigkeit auftreten können, wenn das Zielschema nicht eingefroren ist. Notwendige Ergänzungen können im Code oder in den generierten Skripten vorgenommen werden.