Oracle nach PostgreSQL migrieren: So planst du den Umstieg
Die Datenmigration ist selten das Problem, PL/SQL und die daran hängenden Anwendungen sind es. Rechne den Aufwand ehrlich am Anteil der Stored Procedures hoch, nicht an der Datenmenge, sonst kippt die Planung im ersten Projektdrittel.
Warum die Oracle-Ablösung selten am Schema scheitert, sondern am Code
In den meisten Häusern beginnt das Thema nicht in der Technik, sondern in der Beschaffung. Die jährlichen Lizenz- und Supportkosten stehen im Budget, ein License-Review kündigt sich an, und plötzlich steht die Frage im Raum, welche Datenbanken wirklich Oracle brauchen und welche auf PostgreSQL laufen könnten. Eine Antwort für die ganze Landschaft gibt es nicht: Eine reine OLTP-Anwendung mit weitgehend standardisiertem SQL ist ein anderer Fall als ein gewachsenes System mit PL/SQL-Packages, Oracle Text, Advanced Queuing oder Jobs aus DBMS_SCHEDULER.
Der Schemateil ist dabei der einfachere. Tabellen, Constraints, Indizes und Sequenzen lassen sich mit ora2pg weitgehend automatisch übersetzen, inklusive Typ-Mapping von NUMBER auf numeric oder bigint und von VARCHAR2 auf text. Der eigentliche Aufwand steckt in der Logik. PL/SQL-Packages haben in PostgreSQL kein direktes Gegenstück, Package-Variablen mit Sessionzustand musst du anders lösen, autonome Transaktionen fehlen im Kern, und Hierarchieabfragen mit CONNECT BY wollen als rekursive CTE neu geschrieben werden. ora2pg schätzt den Aufwand dafür, ersetzt aber kein Code-Review.
Drei Fehler siehst du immer wieder. Erstens wird die Anwendung vergessen, obwohl ROWNUM, NVL, DECODE, Abfragen gegen DUAL und Oracle-eigene Treiberdetails oft direkt im Applikationscode stecken. Zweitens wird das Verhalten unterschätzt: PostgreSQL behandelt einen Leerstring nicht wie NULL, sortiert abhängig von der Collation anders und arbeitet mit MVCC ohne Undo-Segmente, was Vacuum und Autovacuum zu einem echten Betriebsthema macht. Drittens fehlt der Rückweg. Wer ohne Parallelbetrieb, Datenabgleich und definiertes Fallback-Fenster umschaltet, hat im Fehlerfall keine Option mehr.
Migrationspfad von Oracle zu PostgreSQL
- 01 Assessment mit ora2pg-Report
- 02 Schema und Typ-Mapping
- 03 PL/SQL zu PL/pgSQL
- 04 Datenübernahme und Abgleich
- 05 Pläne und Tuning
- 06 Parallelbetrieb und Cutover
Der Migrationsweg in klaren Etappen
Eine Migration wird beherrschbar, wenn du sie nicht als ein Ereignis behandelst, sondern als Kette von Schritten mit jeweils eigenem Abnahmekriterium. Diese Reihenfolge hat sich in Projekten bewährt und lässt sich auf einzelne Schemas genauso anwenden wie auf eine ganze Instanz.
Bestand und Machbarkeit bewerten
Lass ora2pg im Report-Modus über das Schema laufen und schau dir die Aufwandsschätzung pro Objekttyp an. Views, Trigger, Packages, externe Tabellen und Datenbank-Links bekommen dabei sehr unterschiedliche Gewichte. Das Ergebnis ist deine Priorisierung: Welches Schema migrierst du zuerst, welches bleibt vorerst auf Oracle.
Schema und Datentypen sauber abbilden
Beim Typ-Mapping entscheidest du bewusst statt automatisch. NUMBER ohne Skalierung wird je nach Wertebereich zu bigint oder numeric, DATE zu timestamp, CLOB zu text. Sequenzen, Identity-Spalten und Default-Werte prüfst du einzeln, ebenso Index-Typen, denn ein Function-Based Index heißt in PostgreSQL Ausdrucksindex und braucht eine als IMMUTABLE markierte Funktion.
PL/SQL nach PL/pgSQL portieren
Packages löst du üblicherweise in Schemas mit einzelnen Funktionen auf, Sessionzustand ersetzt du durch temporäre Tabellen oder Konfigurationsparameter. Autonome Transaktionen bildest du über dblink oder eine Hintergrundverarbeitung ab, CONNECT BY über WITH RECURSIVE. Für Bulk-Logik lohnt der Blick auf mengenbasiertes SQL, weil zeilenweise Cursor in PostgreSQL selten die beste Wahl sind.
Daten übertragen und verifizieren
Für den Erstimport nutzt du COPY statt einzelner INSERTs, ora2pg kann den Export parallelisieren. Anschließend gleichst du ab: Zeilenzahlen pro Tabelle, Prüfsummen über fachliche Schlüssel und Stichproben bei Zahlen, Zeitzonen und Zeichenkodierung. Erst danach legst du Indizes und Constraints an und lässt ANALYZE laufen.
Performance und Ausführungspläne prüfen
Der Planer arbeitet anders als der von Oracle, und Optimizer-Hints gibt es nicht. Statt dessen justierst du work_mem, shared_buffers, effective_cache_size und die Statistikziele, liest Pläne mit EXPLAIN ANALYZE und beobachtest über pg_stat_statements, welche Abfragen wirklich teuer sind. Genau hier zahlt sich Tuning-Wissen aus, wie es der PostgreSQL Advanced-Training zu Performance-Tuning vermittelt.
Betrieb aufbauen, bevor du umschaltest
Backup mit pg_basebackup oder pgBackRest, Point-in-Time-Recovery, Streaming-Replikation, Monitoring und ein geübtes Restore-Verfahren gehören vor den Go-live. Der PostgreSQL Aufbaukurs zu Backup und Datenintegrität deckt diesen Teil ab, der PostgreSQL für Administratoren Grundkurs die Basis darunter.
Kurse zu Migration von Oracle zu PostgreSQL bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Teste dich und finde deinen Weg
Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.
Häufige Fragen zu Migration von Oracle zu PostgreSQL
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktWie viel einer Oracle-Datenbank kann ora2pg automatisch migrieren?
Welche Oracle-Funktionen haben in PostgreSQL kein direktes Gegenstück?
Wie stelle ich sicher, dass nach der Migration keine Daten fehlen?
Ist PostgreSQL für unternehmenskritische Systeme mit Support verfügbar?
Lohnt sich der Umstieg auch von MySQL, MariaDB oder SQL Server?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Migration mit belastbarem PostgreSQL-Wissen angehen
Wenn dein Team den Umstieg selbst tragen soll, braucht es Sicherheit in Administration, Backup und Tuning. Bei cmt findest du dafür den PostgreSQL für Administratoren Grundkurs, den Aufbaukurs zu Backup und Datenintegrität sowie das Advanced-Training zum Performance-Tuning, wahlweise als Live-Online-Termin oder als Inhouse-Schulung auf eure Landschaft zugeschnitten. Sprich uns an, wenn du vorab klären willst, welcher Kurs zu eurem Migrationsstand passt.