Datenmanagement und Datenmigration | 6. August 2026

Oracle‑zu‑PostgreSQL‑Migration Schritt für Schritt mit Ora2Pg

Dieser Beitrag zeigt die detaillierten Schritte zur Migration von Oracle nach PostgreSQL mithilfe von Ora2Pg. Er behandelt unter anderem Installation, Konfiguration, Export, Import sowie Fehlerbehebung.

Von: Dylan

Müssen Sie mit Ora2Pg von Oracle nach PostgreSQL migrieren?

Viele Unternehmen führen Migrationen von Oracle nach PostgreSQL durch, um Lizenzkosten zu senken, erweiterte Funktionen zu nutzen und eine höhere Flexibilität zu erzielen. Für viele Teams bietet der Wechsel zu PostgreSQL eine kostengünstigere und zukunftssichere Datenbankstrategie.

Dennoch ist die Migration von Oracle nach PostgreSQL nicht immer unkompliziert. Oracle‑Datenbanken enthalten oft komplexe Schemas, gespeicherte Prozeduren, Trigger und herstellerspezifische SQL‑Funktionen, die nicht direkt mit PostgreSQL kompatibel sind.

An dieser Stelle erweist sich Ora2Pg als äußerst nützlich. Ora2Pg ist ein beliebtes Open‑Source‑Migrationstool, das die Konvertierung von Oracle‑ nach PostgreSQL‑Datenbanken vereinfacht. Es analysiert Oracle‑Datenbankstrukturen, erstellt Migrationsberichte, wandelt Schemas in PostgreSQL‑kompatibles SQL um und exportiert Daten, die in PostgreSQL importiert werden können.

Lesen Sie einfach weiter; wir zeigen die detaillierten Schritte für die Migration von Oracle nach PostgreSQL mithilfe von Ora2Pg. Dieser Leitfaden wurde in einer CentOS‑Umgebung getestet und behandelt unter anderem Installation, Konfiguration, Tests, Migrationsbewertung, Export‑ und Importschritte.

Teil 1. Ora2Pg installieren

Führen Sie diese strukturierten Schritte (getestet unter CentOS 7/8) aus, um das Tool mit allen erforderlichen Abhängigkeiten zu erstellen und einzurichten:

Schritt 1 – Installieren der zentralen System‑ und Perl‑Abhängigkeiten

Verwenden Sie YUM, um obligatorische Pakete für die Kompilierung und den Betrieb von ora2pg zu installieren:

sudo yum install gcc postgresql-devel perl-DBI perl-ExtUtils-MakeMaker perl-devel perl-DBD-Pg -y

Überprüfen Sie die Installation mit perl -MDBI -e ‚print $DBI::VERSION‘, um sicherzustellen, dass keine Perl‑Module fehlen.

Schritt 2 – Installieren des Oracle Instant Client SDK

1. Laden Sie die Oracle Basic‑ und SDK‑RPM‑Dateien (12.2+) aus dem offiziellen Oracle‑Repository herunter und installieren Sie diese lokal:

sudo yum install oracle-instantclient12.2-basic-12.2.0.1.0-1.x86_64.rpm oracle-instantclient12.2-devel-12.2.0.1.0-1.x86_64.rpm -y

2. Konfigurieren Sie die Umgebungsvariablen in ~/.bash_profile:

export ORACLE_HOME=/usr/lib/oracle/12.2/client64
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export PATH=$ORACLE_HOME/bin:$PATH

Testen Sie die Konnektivität mit sqlplus benutzername/passwort@oracle_host:1521/service_name, um zu bestätigen, dass der Client funktioniert.

Schritt 3 – Erstellen und Installieren des Perl‑Moduls DBD::Oracle

Dieses Modul ermöglicht ora2pg die Verbindung zu Oracle; installieren Sie es der Einfachheit halber über CPAN:

cpan DBD::Oracle

Validieren Sie mit perl -MDBD::Oracle -e ‚print $DBD::Oracle::VERSION‘ (keine Fehler = Erfolg).

Schritt 4 – Erstellen und Installieren von Ora2pg aus dem Quellcode

Laden Sie die stabile Version v20.0 herunter und kompilieren Sie diese:

wget https://github.com/darold/ora2pg/archive/refs/tags/v20.0.tar.gz
tar -xvf v20.0.tar.gz && cd ora2pg-20.0
perl Makefile.PL
make && sudo make install

Bestätigen Sie die globale Installation mit ora2pg -v (es sollte „ora2pg v20.0“ angezeigt werden).

Teil 2. Schritte zur Konfiguration von Ora2pg (ora2pg.conf)

Das Konfigurieren der Datei ora2pg.conf ist der kritische Schritt für die Oracle‑Migration nach PostgreSQL. In dieser Datei wird festgelegt, wie Ora2Pg eine Verbindung zu Ihrer Oracle‑Instanz herstellt, welche Daten migriert werden und wie die Ausgabe für die PostgreSQL‑Kompatibilität formatiert wird.

Schritt 1 – Suchen der Ora2pg‑Konfigurationsdatei

Nach der Installation befindet sich die Standard‑ora2pg.conf üblicherweise unter:

/usr/local/share/ora2pg/ora2pg.conf.dist

Kopieren Sie die Vorlage in eine nutzbare Konfigurationsdatei (behalten Sie das Original bei):

cp /usr/local/share/ora2pg/ora2pg.conf.dist /etc/ora2pg.conf

Schritt 2 – Aktualisieren der zentralen Konfigurationsparameter

Bearbeiten Sie /etc/ora2pg.conf mit einem Texteditor (z. B. vim), um diese an Ihre Oracle‑/PostgreSQL‑Umgebung anzupassen – aktualisieren Sie diese unverzichtbaren Parameter:

# PostgreSQL‑Version (11+ empfohlen)
PG_VERSION = 14

# Oracle‑Verbindungszeichenfolge (Format: dbi:Oracle:host=ORACLE_HOST;port=1521;sid=ORACLE_SID)
ORACLE_DSN = dbi:Oracle:host=192.168.1.100;port=1521;sid=ORCL

# Oracle‑Zugangsdaten (mindestens Lesezugriff)
ORACLE_USER = oracle_migration_user
ORACLE_PWD = Ihr_sicheres_Passwort

# Ziel‑Oracle‑Schema für die Migration
SCHEMA = HR

# Aktivieren des vollständigen Schema‑Exports
EXPORT_SCHEMA = 1

# Export von Benutzerberechtigungen
USER_GRANTS = 1

# Festlegen des Transaktionsmodus auf schreibgeschützt (vermeidet Oracle‑Sperrprobleme)
TRANSACTION = READONLY

Schritt 3 – Validieren der Konfiguration

Prüfen Sie mit einer kurzen ora2pg‑Prüfung auf Syntaxfehler und Konnektivität:

ora2pg -t SHOW_VERSION -c /etc/ora2pg.conf

Bei erfolgreicher Ausführung wird die ora2pg‑Version angezeigt und die Oracle‑Client‑Konnektivität bestätigt.

Teil 3. Testen der Ora2Pg‑Konnektivität

Bevor Sie Migrationsskripte oder Berichte erstellen, empfiehlt es sich, die Ora2Pg‑Konnektivität zu testen, um fehlgeschlagene Migrationen, defekte Exporte und späteren Zeitaufwand zu vermeiden.

Führen Sie diese einfachen Tests durch, um Ihre Einrichtung zu validieren:

Schritt 1 – Testen der grundlegenden Ora2pg‑Installation und ‑Konfiguration

Bestätigen Sie zunächst, dass ora2pg Ihre Konfigurationsdatei erkennt und ohne zentrale Fehler ausgeführt wird:

ora2pg -t SHOW_VERSION -c /etc/ora2pg.conf

Bei erfolgreichem Ergebnis wird die ora2pg‑Version (z. B. „ora2pg v20.0“) ausgegeben und bestätigt, dass das Oracle‑DBD‑Modul geladen ist. Wird „DBD::Oracle not found“ angezeigt, installieren Sie das Perl‑Modul DBD::Oracle erneut (Schritt 3 der Ora2pg‑Installation).

Schritt 2 – Testen der Oracle‑Datenbank‑Konnektivität

Führen Sie einen gezielten Test durch, um zu prüfen, ob ora2pg Ihre Oracle‑Instanz erreichen kann:

ora2pg -t TEST_CONNECTION -c /etc/ora2pg.conf

Bei Erfolg wird „Oracle connection OK“ angezeigt – häufige Fehler, die hier behoben werden müssen:

„Invalid Oracle DSN“: Überprüfen Sie die ORACLE_DSN‑Zeichenfolge in ora2pg.conf (Host, Port, SID‑/Servicename prüfen)
„Authentication failed“: Bestätigen Sie, dass ORACLE_USER und ORACLE_PWD korrekt sind und der Benutzer Lesezugriff auf das Ziel‑Schema hat
„LD_LIBRARY_PATH error“: Überprüfen Sie die Umgebungsvariablen des Oracle Instant Client in ~/.bash_profile

Schritt 3 – Bestätigen des Scans des Oracle‑Schemas

Führen Sie abschließend einen kurzen Scan Ihres Ziel‑Oracle‑Schemas durch, um sicherzustellen, dass ora2pg dessen Objekte lesen kann:

ora2pg -t SHOW_SCHEMA -c /etc/ora2pg.conf

Dieser Befehl listet alle Tabellen, Ansichten und Sequenzen in Ihrem Ziel‑Schema (z. B. HR) auf – eine vollständige Liste bestätigt, dass ora2pg vollen Lesezugriff hat und für die Migrationsbewertung bereit ist.

Teil 4. Ora2Pg‑Migrationsbewertung

Oracle verfügt über viele herstellerspezifische Funktionen (Synonyme, Pakete wie DBMS_*, spezielle PL/SQL‑Logik, verschachtelte Transaktionen), die Ora2Pg nicht automatisch konvertieren kann. Sie sollten das Migrationsrisiko und die geplante Ausfallzeit bewerten, um zu entscheiden, ob Sie fortfahren.

So führen Sie die Migrationsbewertung mit Ora2Pg durch

Schritt 1 – Generieren eines vollständigen Migrationsbewertungsberichts

Führen Sie diesen Befehl aus, um Ihr Oracle‑Schema zu scannen und einen detaillierten, handlungsorientierten Bericht zu erstellen.

ora2pg -t SHOW_REPORT --estimate_cost -c /etc/ora2pg.conf > oracle_to_postgres_assessment.txt

Der Parameter –estimate_cost berechnet einen Migrationsschwierigkeitsgrad (1‑10) und gliedert den Aufwand nach Objekttyp auf (Tabellen, PL/SQL, Partitionen, Berechtigungen usw.).

Schritt 2 – Auswerten des Bewertungsberichts

Prüfen Sie die Datei oracle_to_postgres_assessment.txt und kategorisieren Sie die Objekte nach Konvertierbarkeit:

Vollständig automatisch konvertierbar: Tabellen, einfache Indizes, Sequenzen sowie Primär‑ und Fremdschlüssel‑Constraints (keine manuellen Bearbeitungen erforderlich).
Teilweise konvertierbar: Ansichten, Bereichs‑/Listenpartitionen und einfache gespeicherte Prozeduren (geringe Anpassungen der Postgres‑Syntax erforderlich).
Nicht konvertierbar: Oracle‑spezifische Pakete (z. B. DBMS_UTILITY), Synonyme oder erweitertes PL/SQL (erfordern eine vollständige manuelle Portierung auf PL/pgSQL).

Schritt 3 – Priorisieren der Migrationsaufgaben

Verwenden Sie den Schwierigkeitsgrad des Berichts zur Ressourcenzuweisung:

Wert 1‑3 (Niedrig): Fast vollständige automatische Konvertierung – konzentrieren Sie sich nur auf die Validierung der generierten Skripte.
Wert 4‑7 (Mittel): Planen Sie Anpassungen von PL/SQL → PL/pgSQL sowie Korrekturen der Partitions‑Syntax ein.
Wert 8‑10 (Hoch): Schreiben Sie benutzerdefinierte Oracle‑Pakete/Funktionen vor der Migration für die Postgres‑Kompatibilität um.

Teil 4. Durchführen der Oracle‑zu‑PostgreSQL‑Migration mit Ora2Pg

Nachdem Sie die Konnektivität validiert und eine Migrationsbewertung abgeschlossen haben, können Sie Oracle mit den folgenden Schritten nach PostgreSQL migrieren.

Schritt 1 – Exportieren von Oracle‑Daten/Schema in Postgres‑kompatibles SQL

Wählen Sie einen Exportmodus passend zu Ihrer Bewertung aus (z. B. nur Schema‑Export für hochkomplexes PL/SQL, vollständiger Export für risikoarme Datenbanken)

Vollständiger Export (Schema + Daten + Berechtigungen):

ora2pg -c /etc/ora2pg.conf -o oracle_to_postgres_migration.sql -d

-c: Pfad zur konfigurierten ora2pg.conf
-o: Name der auszugebenden Postgres‑kompatiblen SQL‑Datei
-d: Aktivieren des Datenexports (weglassen für reine Schema‑Exporte)

Benutzerdefinierte Exportoptionen (für zielgerichtete Migrationen)

✵ Reiner Schema‑Export (keine Daten, ideal zum ersten Test der Struktur):

ora2pg -c /etc/ora2pg.conf -o oracle_schema_only.sql -t SCHEMA

✵ Reiner Daten‑Export (für bereits vorhandene Postgres‑Schemas):

ora2pg -c /etc/ora2pg.conf -o oracle_data_only.sql -t DATA

✵ Reiner Berechtigungs‑Export (Benutzerzugriffsrechte):

ora2pg -c /etc/ora2pg.conf -o oracle_grants_only.sql -t GRANTS

Schritt 2 – Validieren des generierten SQL‑Skripts

Importieren Sie niemals ein nicht validiertes Skript – beheben Sie Oracle‑spezifische Syntax, die ora2pg ggf. übersehen hat (gemäß Ihrer Bewertung):

1. Suchen Sie nach nicht konvertierbaren Oracle‑Schlüsselwörtern (z. B. SYNONYM, DBMS_*, NESTED TABLE):

grep -i "SYNONYM\|DBMS_" oracle_to_postgres_migration.sql

2. Beheben Sie die gefundenen Probleme (z. B. Ersetzen von Synonymen durch Postgres‑Ansichten, Umschreiben von PL/SQL in PL/pgSQL)

3. Testlauf des Skripts in Postgres, um Syntaxfehler zu erkennen:

psql -h Ihr_postgres_host -U postgres_user -d ziel_db -f oracle_to_postgres_migration.sql --dry-run

Schritt 3 – Importieren des SQL‑Skripts nach PostgreSQL

Verwenden Sie einen dedizierten Postgres‑Migrationsbenutzer (mit CREATE‑/INSERT‑Berechtigungen), um das validierte Skript zu laden:

psql -h Ihr_postgres_host -p 5432 -U postgres_migration_user -d ziel_postgres_db -f oracle_to_postgres_migration.sql > migration_import_log.txt 2>&1

-h: Postgres‑Server‑Host (localhost bei lokalen Migrationen)
-p: Standard‑Postgres‑Port (5432; bei abweichender Konfiguration anpassen)
-U: Postgres‑Benutzer mit ausreichenden Berechtigungen
-d: Name der Ziel‑Postgres‑Datenbank
> migration_import_log.txt 2>&1: Erfasst alle Protokollausgaben (wichtig für die Fehlersuche bei fehlgeschlagenen Importen)

Dies dient dem Import des Skripts und der Protokollierung aller Ausgaben‑/Fehlermeldungen zur Fehlerbehebung.

Schritt 4 – Überprüfen der Vollständigkeit der Migration

1. Vergleichen Sie Postgres mit Ihrer Oracle‑Quelle, um sicherzustellen, dass keine Daten/Objekte fehlen:

Auflisten der importierten Tabellen (Anzahl mit Oracle abgleichen):

SELECT table_name FROM information_schema.tables WHERE table_schema = 'hr';

2. Validieren Sie die Zeilenanzahl für kritische Tabellen (z. B. employees):

-- Postgres‑Anzahl
SELECT COUNT(*) FROM hr.employees;

-- Oracle‑Anzahl (Vergleichswert)
SELECT COUNT(*) FROM hr.employees;

3. Testen Sie wichtige Constraints (Primär‑/Fremdschlüssel), um die Datenintegrität sicherzustellen:

SELECT employee_id, COUNT(*) FROM hr.employees GROUP BY employee_id HAVING COUNT(*) > 1;

Dies prüft auf doppelte Primärschlüssel und sollte 0 Zeilen zurückgeben.

Hinweis:

Für große Datensätze (100 GB+): Verwenden Sie ora2pg –parallel 4, um Exporte in Blöcke aufzuteilen, und deaktivieren Sie Postgres‑Indizes/Constraints während des Imports (nach dem Import wieder aktivieren für schnellere Ladezeiten)
Produktionsmigrationen: Führen Sie diese während Wartungsfenstern mit geringer Auslastung durch und erstellen Sie vollständige Backups von Oracle (vor dem Export) und Postgres (nach dem Import)
Inkrementelle Synchronisierung: Für aktive Oracle‑Datenbanken verwenden Sie ora2pg -t INCREMENTAL, um neue/aktualisierte Daten nach dem anfänglichen vollständigen Export zu synchronisieren

Teil 5. Häufige Ora2pg‑Migrationsprobleme und Fehlerbehebung

Trotz sorgfältiger Einrichtung können bei einer Oracle‑zu‑Postgres‑Migration mit ora2pg typische Fehler auftreten. Im Folgenden finden Sie die häufigsten Probleme und einfache Lösungen, um den Ablauf auf Kurs zu halten.

1. Fehlende Perl‑Module (DBD::Oracle / DBI‑Fehler)

Dieser Fehler tritt auf, wenn erforderliche Perl‑Bibliotheken fehlen oder beschädigt sind. Installieren Sie die Module DBD::Oracle und DBI neu und bestätigen Sie mit Versionsprüf‑Befehlen, dass diese korrekt geladen werden.

2. Pfadprobleme des Oracle Instant Client

Ora2pg kann aufgrund falscher Umgebungsvariablen keine Oracle‑Client‑Dateien finden. Prüfen und korrigieren Sie ORACLE_HOME und LD_LIBRARY_PATH und laden Sie anschließend Ihr Systemprofil neu.

3. Oracle‑Verbindungs‑ oder Authentifizierungsfehler

Falsche Zugangsdaten, ungültiges DSN‑Format oder Netzwerk‑Blockaden verursachen Verbindungsfehler. Überprüfen Sie Benutzername, Passwort, Host, Port und SID‑/Servicename in ora2pg.conf.

4. Importfehler von PostgreSQL‑SQL‑Skripten

Diese werden durch Oracle‑spezifische Syntax verursacht, die ora2pg nicht automatisch konvertieren kann. Verwenden Sie Ihren Migrationsbericht, um nicht unterstützte Objekte zu finden und diese manuell umzuschreiben.

5. Fehlgeschlagener Export von Berechtigungen

Der Oracle‑Migrationsbenutzer verfügt nicht über ausreichende Lesezugriffsrechte. Gewähren Sie die erforderlichen Lesezugriffe auf das Ziel‑Schema und führen Sie den Export erneut aus.

6. Langsamer Export bei großen Datensätzen

Ora2pg läuft bei großen Tabellen standardmäßig langsam, da es single‑threaded verarbeitet. Verwenden Sie den Parameter –parallel, um den Multi‑Thread‑Export zu aktivieren und den Vorgang zu beschleunigen.

7. Konvertierungsprobleme bei Partitionen oder erweiterten Objekten

Einige Oracle‑Partitionen und benutzerdefinierte Objekte lassen sich nicht direkt auf Postgres abbilden. Passen Sie die Einstellungen in ora2pg.conf an und korrigieren Sie nicht unterstützte Strukturen manuell.

Alternative zu Ora2Pg für sicherere Migrationen ohne Ausfallzeit

Ora2Pg ist zwar ein praktisches Open‑Source‑Tool für kleine, wenig komplexe Oracle‑zu‑PostgreSQL‑Migrationen, weist jedoch kritische Einschränkungen für Unternehmens‑Szenarien auf – insbesondere bei großen Datensätzen (100 GB+) und geschäftskritischen Produktivumgebungen.

Für Unternehmen, die eine schnellere, zuverlässigere Migration ohne Ausfallzeit suchen, bietet i2Stream von Info2Soft – ein führendes heterogenes Datenbank‑Replikationsprodukt – eine Lösung für die zentralen Schwachstellen von ora2pg und stellt Unternehmens‑Funktionen für die Oracle‑zu‑Postgres‑Migration bereit.

Wichtige Vorteile von i2Stream gegenüber Ora2Pg:

Migration ohne Ausfallzeit: i2Stream ermöglicht die Echtzeit‑Datenreplikation während des Migrationsvorgangs. Daten werden kontinuierlich von Oracle nach PostgreSQL synchronisiert, während Anwendungen weiterhin online bleiben. Dadurch können Unternehmen Migrationen abschließen, ohne den Geschäftsbetrieb oder den Benutzerzugriff zu stören.
Einfache Verarbeitung großer Datensätze: i2Stream nutzt eine intelligente parallele Synchronisierung, um große Datensätze automatisch aufzuteilen und effizient zu übertragen. Indizes und Constraints von PostgreSQL bleiben während der Synchronisation erhalten, wodurch zusätzliche Abstimmungen oder Nachprüfungen nach der Migration reduziert werden.
Echtzeit‑inkrementelle Synchronisierung: i2Stream erfasst Oracle‑Redo‑Logs und repliziert Änderungen nahezu in Echtzeit nach PostgreSQL. Dies ermöglicht eine kontinuierliche inkrementelle Synchronisierung über den gesamten Migrationslebenszyklus und gewährleistet die Datenkonsistenz zwischen Quell‑ und Zieldatenbank.
Unternehmens‑Automatisierung: Bei Ora2Pg muss PL/SQL‑Code und herstellerspezifische Syntax manuell umgewandelt werden. i2Stream hingegen passt Oracle‑Datenstrukturen und Logik an PostgreSQL an. Dadurch reduziert sich der manuelle Code‑Umschreibaufwand bei der Migration bestimmter Objekte.
Automatische Datenvalidierung und Überwachung: Automatisierte Datenvalidierung über MD5‑Prüfsummen‑Vergleiche, visueller Abweichungs‑Analyse und Ein‑Klick‑Reparatur. Über ein einheitliches Dashboard können Administratoren Durchsatz, Latenz und Status in Echtzeit verfolgen.

60‑Tage‑kostenlose Testversion

Secure Download

Fazit

Die Oracle‑zu‑PostgreSQL‑Migration mit Ora2Pg ist eine gute Wahl für kleine, wenig komplexe Szenarien. Wenn Sie die schrittweisen Abläufe in diesem Leitfaden befolgen, gelingt Ihnen eine reibungslose grundlegende Migration von Oracle‑ nach PostgreSQL‑Datenbanken.

Für einige Unternehmens‑Anwendungsfälle – mit unvermeidlicher Ausfallzeit, großen Datensätzen – ist jedoch i2Stream von Info2Soft die bessere Wahl. Seine unternehmensgerechte heterogene Replikationsfunktion ermöglicht Migrationen ohne Ausfallzeit, Echtzeit‑Synchronisierung und automatisierte Datenvalidierung. Alle zentralen Schwachstellen von ora2pg werden behoben, sodass ein risikoarmer, effizienter Übergang möglich ist.

Zusätzlich verfügt i2Stream über eine breite Kompatibilität mit vielen weiteren Datenbanken; Sie können Daten zwischen Oracle, MySQL, MS SQL Server und weiteren Systemen migrieren.

Dylan

Keine Kurzbiografie vorhanden