Aufwand messen statt schätzen
ora2pg liefert dir vor der ersten Zeile Code eine Objektliste mit Schwierigkeitsbewertung. Das ist die einzige belastbare Grundlage für die Projektplanung.
# Verzeichnisstruktur, mit der ora2pg selbst arbeitet
ora2pg --project_base /opt/migration --init_project kundendb
# Bewertungsbericht inklusive Aufwandsschätzung je Objekt
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf \
-t SHOW_REPORT --estimate_cost --dump_as_html \
> /opt/migration/bericht.html
# Was steckt überhaupt im Schema?
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf -t SHOW_TABLE
ora2pg -c /opt/migration/kundendb/config/ora2pg.conf -t SHOW_COLUMNDer Bericht rechnet in Aufwandseinheiten, deren Standardwert bei fünf Minuten liegt und über COST_UNIT_VALUE anpassbar ist. Nimm die Zahl nicht als Wahrheit, sondern kalibriere sie: portiere drei mittelgroße Prozeduren wirklich und halte die gemessene Zeit gegen die Schätzung. Der Faktor, den du dabei bekommst, gilt danach für das ganze Projekt.
Was den Aufwand wirklich treibt
| Objektart | Typischer Stolperstein |
|---|---|
| Tabellen und Indizes | Läuft weitgehend automatisch, Prüfaufwand steckt in den Datentypen |
| Views | Meist automatisch, außer bei CONNECT BY und Oracle-eigenen Funktionen |
| PL/SQL-Pakete | Hauptaufwand. Zustand in Paketvariablen hat in PostgreSQL kein Gegenstück |
| Trigger | Andere Struktur: PostgreSQL braucht eine Funktion plus getrenntes CREATE TRIGGER |
| Jobs aus DBMS_SCHEDULER | Kein Gegenstück im Kern, wandert nach pg_cron oder auf systemd-Timer |
| SQL im Anwendungscode | Taucht im Bericht nicht auf und wird trotzdem der teuerste Posten |