Warum auf PostgreSQL migrieren? Was sind die Vorteile und Grenzen des Tools Ora2Pg? Unser Experte Bertrand erklärt alles und teilt seine Ratschläge anhand eines Kundenprojekts.
Warum von Oracle zu PostgreSQL migrieren?
Der Kunde, ein großes Unternehmen für Fahrzeugwartung und -reparatur, hatte das Ziel, langfristig Kosten zu senken. PostgreSQL bietet zudem mehr Flexibilität.
Nach der Analyse der IT-Ressourcen (Server, Datenbanken usw.) hinsichtlich Technologien, Volumen und Versionen wurde entschieden, in die AWS-Cloud zu migrieren. Durch die Migration zu PostgreSQL konnten langfristig Einsparungen erzielt werden.
Der Kontext der Migration: 14 maßgeschneiderte Anwendungen
Natürlich beginnt jedes Migrationsprojekt mit einer Architekturphase, gefolgt von der eigentlichen Migrationsphase.
Die Produktionsumgebung wurde nicht geändert, um das Migrationsrisiko zu minimieren (physische Maschine zu physischer Maschine), während andere Umgebungen in die Cloud verlagert wurden.
Insgesamt wurden 14 maßgeschneiderte Anwendungen von Oracle zu PostgreSQL migriert, darunter mehr als 1400 Funktionen und Prozeduren für die Hauptanwendung.
Alle diese Anwendungen funktionierten nach demselben Prinzip: ein DAL (Data Access Layer) und Prozeduren für jeden Datenbankaufruf. Es wurden keine Abfragen in den Anwendungen verwaltet. Daher wurde beschlossen, die Anwendungen nicht zu ändern, sondern nur die Verbindungsebene. Dies ist ein eher seltener Fall für eine Migration von Oracle zu PostgreSQL, war aber dank dieser Anwendungsarchitektur möglich.
Der Großteil des Migrationsprojekts bestand aus der Anpassung der Datenbank, einschließlich der Neuschreibung von Code, technischer und funktionaler Validierungen sowie Leistungsvalidierungen.
Welche Methodik für die Migration von Oracle zu PostgreSQL?
Um den verschiedenen Projektanforderungen gerecht zu werden, haben wir eine Methodik in 5 Schritten gewählt:
- Verwendung von Ora2Pg, einem Tool, das den für die Migration benötigten Zeitaufwand schätzt und die Syntax von Oracle zu PostgreSQL konvertiert.
- Durchführung eines Proof of Concept (PoC), um eine repräsentative „kleine“ Anwendung zu PostgreSQL zu migrieren.
- Manuelle Korrektur von fehlerhaften Funktionen mittels wiederholbarer Skripte.
- Automatisierung bestimmter notwendiger Korrekturen, da die PostgreSQL- und Oracle-Treiber unterschiedlich funktionieren: Änderung einer Rückgabe von refcursor zu einer Rückgabe von record. Die Änderung hätte auch auf Anwendungsebene vorgenommen werden können, aber die Entscheidung fiel zugunsten der Datenbank.
- Implementierung automatisierter Regressionstests für alle Prozeduren.
Beispiel für die Migration einer Anwendung mit Ora2Pg
- Initialisierung eines Ora2Pg-Projekts.
- Erste Testmigration der Anwendung mit Ora2Pg.
- Korrektur von Funktionen, Prozeduren, Ansichten und Flüssen, die nicht kompiliert werden, sowie fehlerhafter Tabellen und Indizes.
- Automatisierte Unit-Tests.
- Korrektur von Funktionen, Prozeduren, Ansichten und Flüssen, die Fehler verursachen oder aufgrund von Leistungsproblemen Timeouts erzeugen.
- Regressionstests und Leistungstests.
- Korrektur der aufgetretenen Probleme (Fehler, die nicht durch Unit-Tests erfasst wurden, Leistungsprobleme usw.).
- Für die einfachsten Anwendungen: Produktionsstopp und erneute Migration mit Ora2Pg.
- Für die Hauptanwendung: Die Produktion wird nur mit der Tabellenstruktur regeneriert. Nicht geänderte Daten werden im Voraus migriert. Am Tag der Migration: Produktionsstopp, Migration der verbleibenden Daten, Wiederherstellung der Sequenzen (mit Ora2Pg) und Neuerstellung der Indizes und Constraints.
Erfahrungsbericht zur Migration von Oracle zu PostgreSQL mit Ora2Pg
Unsere Experten haben verschiedene positive und negative Punkte zur Nutzung von Ora2Pg sowie Ratschläge für eine reibungslosere Migration von Oracle zu PostgreSQL aufgelistet.
Es handelt sich nicht um vollständige Listen, sondern um Erfahrungsberichte aus der Migration für unseren Kunden, einen Spezialisten für Fahrzeugreparaturen.
Die Vorteile von Ora2Pg
Die Datenmigration verlief problemlos, und die verschiedenen Konvertierungen wurden ohne Probleme durchgeführt.
Eine signifikante Anzahl von Prozeduren konnte ohne größere Änderungen konvertiert und direkt genutzt werden.
Die Grenzen von Ora2Pg
Ora2Pg ist kein Allheilmittel. Wir sind auf verschiedene Grenzen des Tools gestoßen: keine Konvertierung von Zeichenketten, Bugs bei Variablen, die mit „return“ enden, etwa 25 % manuelle Korrekturen (mehr oder weniger komplex) bei den Prozeduren (z. B. muss die Anweisung MERGE in INSERT ON CONFLICT DO UPDATE umgewandelt werden).
Ora2Pg ändert nur die Daten und den Code in der Datenbank. Es berührt nicht die Anwendung oder die außerhalb der Datenbank liegenden Flüsse. In unserem Fall waren die Flüsse nicht zu zahlreich (ca. 50), aber ihre Migration war fast genauso zeitaufwendig wie die der Datenbank
Worauf man bei der Migration von Oracle zu PostgreSQL achten sollte
Einige Oracle-Funktionen existieren in PostgreSQL einfach nicht. Dies muss im Voraus berücksichtigt werden. In unserem Fall betraf dies nur eine geringe Anzahl von Prozeduren: 4, von denen 2 nicht mehr verwendet wurden.
Die Besonderheiten von PostgreSQL
Jede Technologie hat ihre eigenen Besonderheiten. Ein Überblick über die aufgetretenen Fälle:
- Ein häufiges Problem ist, dass PostgreSQL sehr strikt bei den Typen ist. Man kann keinen char in ein varchar oder einen integer in ein numeric zuweisen, was zu zahlreichen Fehlern führen kann.
- Ein weiteres Problem aufgrund der strikten Typisierung in PostgreSQL: Wir mussten für alle Vorkommen von clock_timestamp() (entspricht sysdate) einen cast hinzufügen, da es standardmäßig ein timestamp with timezone ist, während ein timestamp without timezone gewünscht war.
- Ein weiteres Typisierungsproblem: Ein Standardtyp wird für Konstanten in select-Klauseln vergeben, der nicht immer der gewünschte ist, sodass auch hier casts hinzugefügt werden müssen (z. B. ist null standardmäßig Text).
- Es gab auch Leistungsprobleme bei komplexen Abfragen (insbesondere bei Flüssen/Batches). Der PostgreSQL-Abfrageplaner ist weniger leistungsfähig als der von Oracle, insbesondere bei der Integration von Inline-Views in die Abfrage. Außerdem gibt es keine Hints, sodass man mit Funktionen auf den Spalten spielen muss, um bestimmte Indizes zu deaktivieren usw.
- Der Kunde entschied sich, nur den Typ numeric für Zahlen zu verwenden, um die Migration zu vereinfachen. Es ist möglich, dass dies nicht die beste Wahl war (Leistung bei Operationen auf diesem Feldtyp ist schlechter als bei integers).
- Es gibt keine Packages in PostgreSQL. Packages werden in Schemas umgewandelt, die die Funktionen und Prozeduren enthalten: Alle globalen Variablen/Konstanten müssen ersetzt werden.
- Die Tests und Leistungsanpassungen der Flüsse können viel Zeit in Anspruch nehmen (z. B. 6 Tage für einen einzigen Fluss).
- Bei der Umstellung auf PostgreSQL musste die Überwachungslösung angepasst werden, sodass Tools gesucht werden mussten, die die ressourcenintensivsten Abfragen erfassen (Dynatrace / Datasentinel / pganalyze).
Einige Tipps für eine einfachere Migration
Hier sind drei Tipps von unserem Experten zur Nutzung von Ora2Pg:
- Einrichtung von Unit-Tests für die Hauptanwendung, um Fehler nach der ersten Migration mit Ora2Pg schnell zu identifizieren.
- Leistungstests für die wesentlichen Funktionen der Anwendung sind wichtig. In unserem Fall konnten signifikante Unterschiede gefunden und korrigiert werden.
- Mit Ora2Pg ist es möglich, Daten im Voraus zu kopieren, wenn man die unveränderten Daten in der Datenbank definieren kann.
Sollte man Ora2Pg verwenden?
Für die einfacheren Anwendungen hat Ora2Pg 80% bis 100% der Arbeit erledigt, und es gab kaum Probleme. Die Migration der Hauptanwendung wurde jedoch mehrfach verschoben, um Leistungs- und Regressionstests durchzuführen.
Bei der Migration der größten Anwendung haben einige Funktionen die Datenbank stark belastet, und die Anzahl der Sitzungen auf pgpool (Verbindungsproxy) war nicht ausreichend, was zu Blockierungen führte. Schließlich konnten alle kritischen Probleme schnell gelöst und die wenigen signifikanten Leistungsprobleme am ersten Tag behoben werden.
Die Leistung der Anwendung und der Flüsse auf PostgreSQL entspricht den Erwartungen des Kunden. Das bedeutet nicht, dass alles genauso schnell ist wie auf Oracle. Einige Flüsse oder Prozeduren/Funktionsaufrufe sind langsamer (bis zu 50% langsamer), andere sind schneller (bis zu 30% schneller) nach Optimierung. Insgesamt sind die Leistungen ausgeglichen zwischen der alten und der neuen Infrastruktur.
Zusammenfassend war Ora2Pg ein Werkzeug, das uns bei dieser Migration geholfen hat, aber es war notwendig, verschiedene Kollegen einzubeziehen, um die Migration erfolgreich zu gestalten. Das Tool hilft, aber es erledigt nicht alles, und es wurde besonderer Aufwand betrieben, um automatisierte Unit- und Leistungstests durchzuführen, um die Migration zu erleichtern.
