Der Kunde betreibt eine seiner wichtigen Businessanwendungen inkl. zugehöriger Datenbank in der AWS-Cloud. Aufgrund der hohen Lizenzkosten sollte die damals genutzte Oracle- durch eine PostgreSQL-Datenbank ersetzt werden. Die Anwendung wird montags bis freitags genutzt, weshalb die Datenmigration an einem Wochenende stattfinden musste. Es musste zwei Wochen lang möglich sein, auf die Oracle-Datenbank zurückzuwechseln.

AWS DMS [1] ist ein Service für Datenbankmigrationen innerhalb der AWS-Cloud. Man definiert Replikations-Tasks, um die Daten aus den Tabellen zwischen den Datenbanken zu übertragen. Diese werden auf einer Replikations-Instanz ausgeführt. Damit die Tasks auf die Datenbanken zugreifen können, müssen zusätzlich Endpunkte konfiguriert werden [2].

Der erste Versuch die gesamte Datenbank in einem Durchgang zu migrieren dauerte zu lange. Um die Migration zu beschleunigen haben wir die Tabellen der Größe nach in mehrere Tasks aufgeteilt, die wir mit einer stärkeren Replikations-Instanz parallel ausgeführt haben. Damit die Oracle-Datenbank den höheren Durchsatz effizient verarbeiten konnte haben wir temporär eine größere Instanz gewählt, Constraints deaktiviert und Indices erst nach der Migration aufgebaut.

1. Duplicate Key Violations
Beim Speichern traten plötzlich Konflikte auf – Ursache war, dass AWS DMS keine Sequences überträgt. Mit einem SQL-Skript, das den höchsten Schlüsselwert je Tabelle ermittelt, konnten wir die Sequences aktualisieren.

2. Boolean-Mapping-Fehler
Tabellen mit Boolean-Spalten wurden nicht korrekt übertragen. In den Logs erschien: „Error: ‚true‘ is not a valid boolean“!
AWS DMS mappt Datentypen als erstes auf einen internen Typ und anschließend auf den passenden Typ für die Zieldatenbank. Der Orcale Typ number(1,0) wird auf BOOLEAN gemappt. Standardmäßig wird BOOLEAN zu varchar(5) transfomiert. In der Zieldatenbank haben wir die Spalte aber mit boolean definiert, was zu dem Fehler führte. Durch eine Konfiguration an dem Endpunkt konnte das Mapping korrigiert werden.

3. Nicht migrierte Tabelle ohne Fehlermeldung
Eine Tabelle wurde komplett ignoriert – ohne Hinweis in den AWS DMS Logs. Sie unterschied sich auf den ersten Blick nicht von den anderen Tabellen.
Auf den zweiten Blick fiel auf das eine der Spalten einen sehr sperrigen Namen hatte (VALUE_ADDED_TAX….). Es stellte sich raus, dass Spaltennamen, die länger als 38 Zeichen sind, werden von AWS DMS ignoriert – vermutlich ein Überbleibsel aus Zeiten, in denen Oracle diese Länge beschränkte.

Neben der einmaligen Replikation („Full Load“) unterstützt AWS DMS auch eine fortlaufende Replikation („Change Data Capture“), die auf Transaktionslogs basiert. Änderungen werden dabei nicht direkt aus der Datenbank, sondern aus den Logs ausgelesen und auf die Zieldatenbank übertragen – vorausgesetzt, die Logs stehen lange genug zur Verfügung.
Wir planten, PostgreSQL und Oracle für zwei Wochen synchron zu halten, um im Fall eines Rollbacks zurückwechseln zu können.

Beim Testen traten Probleme bei der Rückreplikation auf. Besonders auffällig: ein Fehler bei der Verarbeitung von Datumswerten. Während PostgreSQL das Format „YYYY-MM-DD“ nutzt, war in Oracle standardmäßig „MM/DD/YYYY“ hinterlegt. Diese Abweichung führte zu einem ORA-01843-Fehler. Da AWS DMS diesen Parameter beim Verbindungsaufbau nicht überschreibt, setzten wir gezielt einen LOGON-Trigger ein, um das Format nur für den DMS-User korrekt zu setzen. Auch bei CLOB-Werten kam es zu unerwartetem Verhalten. Obwohl TEXT-Werte von PostgreSQL beim Rückschreiben als CLOB erwartet wurden, blieben die Felder leer. AWS DMS unterstützt kein direktes Mapping in diese Richtung. Unsere Lösung: manuelle Migration der betroffenen Spalten.

Dazu exportierten wir die Daten als CSV, nummerierten sie durch, importierten sie in eine temporäre Tabelle und aktualisierten die Zielspalten gezielt anhand der Indizes.

Da eine vollständige Migration nicht an einem Wochenende möglich war, entschieden wir uns für eine zweistufige Vorgehensweise:
Zuerst migrierten wir alle Daten bis zu einem festgelegten Stichtag, danach das Delta der neu hinzugekommenen Daten.
Die Oracle-Datenbank wurde an einem Wochenende geklont, während die Anwendung gestoppt war. Anschließend konnten wir alle bis zum Stichtag vorhandenen Daten in die neue PostgreSQL-Datenbank übertragen. Neue Daten, die nach dem Stichtag eingingen, wurden weiterhin in Oracle und den Transaktionslogs gespeichert.
Diese Logs bildeten die Grundlage für eine fortlaufende Replikation. Nach wenigen Tagen war das Delta ebenfalls übertragen und die Systeme synchron. Die Anwendung konnte nun auf PostgreSQL umgestellt werden. Zur Sicherheit hielten wir die Synchronisierung via Rückreplikation noch zwei Wochen aufrecht, bevor Oracle endgültig abgeschaltet wurde.