Oracle nach PostgreSQL: 3 Fragen, die in jedem Migrationsprojekt kommen

Wer eine Oracle-Migration begleitet, hört dieselben 3 Fragen immer wieder. Sie stehen in keinem Migrationsleitfaden, weil sie nicht aus der Theorie kommen, sondern aus der Arbeit: Wie halten wir Datentypen wartbar, warum funktionieren manche Views nicht auf Anhieb und wie beweisen wir am Ende, dass wirklich alles korrekt übernommen wurde?

1. „Machen wir doch einfach alles auf Text"

Diese Idee kommt fast immer, sie hat einen nachvollziehbaren Grund. In Oracle ist eine Längenänderung an einer Spalte lästig. Aus VARCHAR2(50) soll VARCHAR2(80) werden, weil ein Lieferantenname nicht mehr passt. Bei größeren Tabellen bedeutet das Aufwand, Abstimmung und ein Wartungsfenster. Wenn so etwas mehrmals im Monat vorkommt, entsteht daraus eine sehr rationale Schlussfolgerung: Wir nehmen künftig überall den größtmöglichen Texttyp, dann ist Ruhe.

Der Punkt ist nur: Das ist eine Antwort auf ein Oracle-Problem, das PostgreSQL nicht hat.

Was in PostgreSQL anders ist

2 Eigenschaften ändern die Rechnung vollständig:

• Kein Unterschied in der Speicherung. text und varchar(n) werden intern identisch abgelegt. Es gibt keinen Geschwindigkeitsvorteil für den einen oder den anderen Typ. Die Längenangabe ist reine Prüfung, kein Speicherformat.
• Vergrößern kostet nichts. Seit PostgreSQL 9.2 erfordert das Erhöhen einer varchar-Länge keinen Tabellen-Rewrite mehr. Es ist eine Katalogänderung und damit praktisch sofort fertig, unabhängig von der Tabellengröße.

Damit verschwindet der Schmerz, der die Strategie überhaupt erst erzeugt hat. Die Längenänderung, die unter Oracle ein Wartungsfenster brauchte, ist in PostgreSQL eine Sache von Sekunden.

Was Sie aufgeben, wenn Sie trotzdem alles auf Text setzen

Die Längenbegrenzung ist die billigste Datenprüfung, die es gibt. Sie kostet keine Anwendungslogik, sie greift immer und sie greift auch dann, wenn Daten über einen Importjob oder direkt per SQL hereinkommen statt über die Anwendung. Wer sie pauschal entfernt, verlagert diese Prüfung in den Anwendungscode oder verliert sie ganz.

Die Folgen sind unspektakulär, aber lästig: Ein Nachname mit 4.000 Zeichen aus einem fehlerhaften Import, Formularfelder ohne serverseitige Grenze, Berichte mit zerschossenem Layout. Nichts davon legt ein System lahm, alles davon kostet später Zeit.

Ein Detail, das in der Diskussion oft fehlt: Verkleinern ist weiterhin teuer. Eine Länge nach unten zu setzen erfordert eine Prüfung der vorhandenen Werte. Wer Grenzen also einmal aufgibt, bekommt sie nicht mehr billig zurück.

Die praktikable Antwort liegt in der Mitte. Behalten Sie Längen dort, wo es eine fachliche Grenze gibt, etwa bei Schlüsseln, Kennzeichen und Codes. Nehmen Sie text dort, wo ohnehin keine sinnvolle Obergrenze existiert, etwa bei Beschreibungen und Kommentaren. Die Migration ist der richtige Moment für diese Entscheidung, weil Sie die Spalten ohnehin einzeln anfassen.

2. „74 von 78 Views liefen sofort — warum reden alle über die 4?"

Ein typisches Zwischenergebnis einer Migration: Von 78 Views werden 74 automatisch korrekt übersetzt, 4 brauchen Nacharbeit. Das ist eine Quote von 95 %. Für ein Werkzeug, das SQL zwischen 2 Systemen übersetzt, ist das ein sehr gutes Ergebnis.

In der Wahrnehmung passiert trotzdem etwas anderes. Die 74 funktionierenden Views sieht niemand, weil funktionierende Dinge unsichtbar sind. Die 4 kaputten stehen im Fehlerprotokoll, kosten einen Nachmittag und prägen den Eindruck. Aus „das Werkzeug hat 95 % erledigt" wird im Kopf „das Werkzeug ist unzuverlässig".

Warum es immer ein Rest bleibt

Die Ausfälle sind nicht zufällig verteilt. Sie sammeln sich dort, wo Oracle-spezifisches SQL im Spiel ist: hierarchische Abfragen, proprietäre Funktionen, Besonderheiten bei Datums- und Zeitverarbeitung, verschachtelte Konstrukte, die in PostgreSQL anders formuliert werden. Ein Übersetzer kann Muster abbilden, die er kennt. Was strukturell anders gelöst werden muss, kann er nicht erraten.

Deshalb ist die 95-%-Quote auch kein Zufallswert, sondern erwartbar. Eine Migration, bei der 100 % der Views auf Anhieb laufen, hat entweder sehr einfache Views oder ein Prüfproblem.

Was das für die Projektplanung heißt

Setzen Sie die Nacharbeit von Anfang an in den Plan, statt sie als Störung zu behandeln. 2 Zahlen helfen dabei mehr als jede Diskussion: Wie viele Objekte gibt es und welcher Anteil braucht Handarbeit. Ist das vorher benannt, ist die Nacharbeit ein eingeplanter Posten. Fehlt es, wirkt jeder gefundene Fehler wie ein Rückschlag.

Für die Kommunikation im Projekt ist die Umkehrung nützlich: Nicht „4 Views sind fehlgeschlagen", sondern „74 Views sind ohne Eingriff übernommen, 4 brauchen je etwa eine Stunde". Dieselbe Tatsache, eine völlig andere Wirkung auf ein Lenkungsgremium.

3. „Wie beweisen wir, dass alles korrekt migriert ist?"

Die Frage kommt spät und ist die wichtigste von allen. Die Daten sind übertragen, die Anwendung startet, die Stichproben sehen gut aus. Nur will jemand das schriftlich haben, bevor das alte System abgeschaltet wird.

Der naheliegende Gedanke lautet meist: Wir bilden Prüfsummen über die Tabelleninhalte auf beiden Seiten und vergleichen sie. Das funktioniert tatsächlich, aber der Hash ist der einfache Teil.

Die Werkzeuge gibt es

Oracle bringt seit Version 12.1 die Funktion STANDARD_HASH mit, die direkt in SQL nutzbar ist und unter anderem SHA-256 beherrscht. PostgreSQL hat seit Version 11 eine eingebaute sha256-Funktion. Beide erzeugen denselben Hash, sofern sie dieselben Bytes bekommen.

Dieselben Bytes zu bekommen ist die eigentliche Arbeit

Hier liegen die Fallen, die erste ist die gemeinste:

• Leerstring gegen NULL. Oracle behandelt eine Zeichenkette der Länge 0 als NULL, PostgreSQL unterscheidet beides. 2 fachlich identische Datenbestände liefern damit unterschiedliche Hashes, ohne dass ein Fehler vorliegt.
• Verkettung mit NULL. In Oracle ergibt die Verkettung eines Werts mit NULL den Wert selbst, in PostgreSQL ergibt sie NULL. Ohne ein ausdrückliches COALESCE auf einen Platzhalter hashen Sie auf beiden Seiten etwas anderes.
• Zahlen und Datumswerte brauchen auf beiden Seiten eine explizite Formatmaske. Sonst entscheiden Session-Einstellungen über Nachkommastellen und Datumsformat. Das Ergebnis wird dann zufällig.
• Auffüllung bei CHAR. Oracle füllt mit Leerzeichen auf. Diese müssen vor dem Hashen entfernt werden.
• Reihenfolge. Zeilen kommen in unterschiedlicher Sortierung zurück. Entweder sortieren Sie deterministisch nach Primärschlüssel oder Sie aggregieren die Zeilen-Hashes reihenfolgeunabhängig.

Machbar ist das alles. Nur ist es ein eigenes kleines Projekt. Wenn die Vereinheitlichung an einer Stelle nicht stimmt, jagen Sie tagelang Abweichungen, die keine sind.

Die Prüfleiter, die ich empfehle

4 Stufen, von billig nach teuer. Die meisten Projekte brauchen die vierte nie:

• Zeilenzahlen je Tabelle. Der billigste Test überhaupt. Er findet abgebrochene Ladeläufe, vergessene Tabellen und Filterfehler, also die häufigsten Fehlerklassen.
• Aggregate je Spalte. Summe, Minimum und Maximum bei Zahlen, Anzahl der NULL-Werte, maximale Länge bei Texten. Das findet fast alles Inhaltliche und kommt ohne Vereinheitlichungs-Aufwand aus, weil Sie Zahlen mit Zahlen vergleichen statt Zeichenketten mit Zeichenketten.
• Die eingebaute Prüfung des Migrationswerkzeugs. Ora2Pg kann das bereits: Die Aktion TEST_COUNT liefert den Zeilenzahl-Vergleich zwischen Oracle und PostgreSQL, TEST_DATA prüft die Inhalte und kann mehrere Tabellen parallel abarbeiten. Die Abweichungen landen in einer Protokolldatei. Über eine Konfigurationsoption legen Sie fest, nach wie vielen Abweichungen je Tabelle abgebrochen wird. Wer ohnehin mit diesem Werkzeug migriert, hat die Antwort auf die Prüffrage bereits im Haus.
• Zeilen-Hashes. Erst danach und nur für die Tabellen, bei denen es wirklich darauf ankommt. Dann aber mit sauber definierter Vereinheitlichung und dokumentierten Regeln.

Der Reflex, sofort mit Hashes zu starten, ist verständlich, weil er nach dem strengsten Beweis klingt. In der Praxis finden die Stufen 1 und 2 den Großteil der Fehler in einem Bruchteil der Zeit.

Was die 3 Fragen verbindet

Alle 3 entstehen an derselben Stelle: Ein Team überträgt Erfahrungen aus dem alten System auf das neue, ohne zu prüfen, ob die Voraussetzungen noch gelten. Die Text-Strategie löst ein Oracle-Problem, das PostgreSQL nicht hat. Die Enttäuschung über die 4 Views entsteht aus einer Erwartung, die niemand vorher ausgesprochen hat. Der Wunsch nach Hashes wiederum ist der Reflex, Sicherheit über das aufwendigste verfügbare Mittel herzustellen, statt über das wirksamste.

Das ist kein Vorwurf, sondern die normale Begleiterscheinung eines Systemwechsels. Wer diese 3 Punkte früh anspricht, spart sich die Diskussionen später — meist genau dann, wenn ohnehin wenig Zeit ist.

Wie sich der Aufwand vorher beziffern lässt, steht in Von Oracle zu PostgreSQL: was die Migration wirklich kostet. Wer statt Oracle einen SQL Server ablösen will, findet die Unterschiede in SQL Server nach PostgreSQL.

Häufige Fragen

Sollte man in PostgreSQL text oder varchar verwenden?

Technisch gibt es keinen Unterschied: Beide Typen werden intern identisch gespeichert, es gibt keinen Geschwindigkeitsvorteil. Die Längenangabe bei varchar(n) ist eine kostenlose Datenprüfung. Sinnvoll ist deshalb eine Mischung: Längen dort, wo es eine fachliche Grenze gibt, text dort, wo keine existiert.

Ist eine Längenänderung in PostgreSQL aufwendig?

Das Vergrößern nicht. Seit PostgreSQL 9.2 erfordert das Erhöhen einer varchar-Länge keinen Tabellen-Rewrite und ist damit unabhängig von der Tabellengröße praktisch sofort erledigt. Das Verkleinern erfordert weiterhin eine Prüfung der vorhandenen Werte und ist entsprechend teurer.

Kann man Tabelleninhalte zwischen Oracle und PostgreSQL über Hashes vergleichen?

Ja. Oracle bietet seit Version 12.1 STANDARD_HASH, PostgreSQL seit Version 11 eine eingebaute sha256-Funktion. Der Aufwand liegt nicht im Hashen, sondern darin, auf beiden Seiten exakt dieselben Eingabebytes zu erzeugen: Leerstring gegen NULL, Verkettung mit NULL, Zahlen- und Datumsformate, Auffüllung bei CHAR und die Zeilenreihenfolge müssen ausdrücklich vereinheitlicht werden.

Wie viele Views laufen bei einer Migration typischerweise auf Anhieb?

Eine hohe Quote ist normal, der Rest sammelt sich dort, wo Oracle-spezifisches SQL im Spiel ist: hierarchische Abfragen, proprietäre Funktionen und Besonderheiten der Datumsverarbeitung. Wichtig ist, diese Nacharbeit vorher einzuplanen, statt sie als Fehlschlag des Werkzeugs zu behandeln.

Der ehrliche Schluss

Migrationen scheitern selten an der Technik. Sie scheitern an Erwartungen, die niemand ausgesprochen hat, und an Gewohnheiten, die im alten System richtig waren. Die 3 Fragen oben sind gute Gesprächsanlässe, weil sie früh klären, worüber später sonst gestritten wird.