Immer häufiger werden wir mit der Frage konfrontiert, wie und ob man eine Oracle Datenbank nach PostgreSQL migrieren kann. Diese Frage ist nicht immer einfach zu beantworten. Technisch ist dies natürlich möglich. Ob es allerdings auch aus betriebswirtschaftlichen Gründen (Aufwand der Migration vs. Kostenersparnis Oracle) sinnvoll ist, steht auf einem anderen Blatt.

In diesem Beitrag soll es jedoch um den ersten Teil der Frage gehen. Dazu stellen wir Ihnen das GPL Tool ora2pg in einem einfachen Beispiel vor. Die komplette Dokumentationen mit allen Optionen und Facetten des Werkzeuges finden Sie hier:  https://ora2pg.darold.net/documentation.html 

Das Fundament: Die Installation von ora2pG

Bei dem Werkzeug ora2pg handelt es sich um eine Perl-Applikation, die sich dementsprechend einfach installieren lässt. Neben einer aktuellen Perl-Version, die auf den üblichen Linux-/Unix-Derivaten meist per Default installiert ist, benötigt die Applikation auch die notwendigen Treiber- und Client-Bibliotheken für den Zugriff auf die Oracle DB:

• DBD::Oracle; Perl Modul für den Oracle Zugriff
• Oracle (Instant) Client
  
  

Wer es sich an dieser Stelle einfach machen möchte, kann natürlich die Applikation auch auf dem Oracle Server installieren und die Oracle Perl Distribution verwenden. Dazu muss nur der Pfad so umgesetzt werden, dass diese Perl-Version auch gefunden wird.

Die Brückenpfeiler: Die Extraktion des Schemas & Daten

Vor einer Migration empfiehlt es sich, ein Projekt zu erzeugen. Generell sorgt dies dafür, dass alle Skripte und Konfigurationen für unsere Migration in einem Verzeichnis gekapselt werden.

Unterhalb dieser Dateistruktur befindet sich auch die Konfigurationsdatei. Hier lassen sich umfangreiche Einstellungen vornehmen. Unter anderem muss hier die DB-Verbindung (zu Oracle) definiert werden. Zusätzlich lassen sich beispielsweise alle möglichen Filter (z.B. für DB-Objektname und/oder -typen) aber auch andere Einstellungen (Character-Sets, Umgang mit Constraints, Parallelität, ...) festlegen.

Im Folgenden sehen Sie einige wenige Ausschnitte der Konfiguratio:

Oracle-kundige Leser werden gesehen haben, dass wir das Beispiel-Schema "hr" aus der Oracle Datenbank exportieren wollen. Es enthält einige Objekte (Tabellen, Views, Sequenzen, Trigger, Prozeduren, ...) und auch ein paar Datensätze. Wir exportieren dieses Schema aus einer pluggable Databases (XEPDB1) aus Oracle 18c Instanz mit dem Namen "XE".

Der Bauplan: Lohnt das überhaupt?

Mit der Extraktion des Schemas (und der Daten – es kann übrigens auch nur das Schema oder die Daten extrahiert werden), erstellt ora2pg einen übersichtlichen Report.

Unter anderem wird bestimmt, welche Objekte migriert werden und ob es beim Prozess zu Problemen und/oder Workarounds kommt. In dem Beispiel-Report ist u.a. zu sehen, dass es zahlreiche Synonyme gibt, die durch Views ersetzt werden sollen (dazu später mehr). Probleme werden mit Kosten gewichtet.

Am Ende des Reports ist zu sehen, mit welchen Problemen und Kosten bei der Migration (z.B. durch Nacharbeiten) zu rechnen ist. Natürlich ist dies nur ein grober Richtwert. Bei einer großen Anzahl von Oracle-Systemen, die migriert werden sollen, kann dies aber bereits ein erster Anhaltspunkt sein, wo sich die "Low-hanging Fruits" befinden.

In unserem einfachen Beispiel wird der Aufwand als "A-3" klassifiziert. Die Migration sollte damit weitestgehend automatisch ("A") und mit einem moderaten technischen Skill ("3") möglich sein.

Der Brückenschlag

Der Bau der eigentlichen Brücke besteht aus drei Teilen. Zunächst erfolgt der Export des Schemas. Dies geschieht über den unspektakulären folgenden Aufruf eines Kommandos (Ausgabe stark gekürzt):

Der zweite Teil besteht aus dem Export der Daten. Das Kommando wird vom vorherigen Befehl geliefert (Ausgabe stark gekürzt):

Der dritte Teil besteht nun darin, die Daten (das Projekt-Verzeichnis) auf den PostgreSQL Server zu kopieren und zu laden. Dies passiert ebenfalls über ein Skript, welches von ora2pg generiert wurde.

Beim Import in den PostgreSQL-Server ist der DB-Name (-d), die Liste der zu ladenden Schemata (oder auch nur eines; -n) und der DB-Owner (-o) zu spezifizieren. Alle weiteren Parameter können dialogorientiert eingegeben werden (oder natürlich auch als Parameter; Ausgabe wieder stark gekürzt):

Auf zwei Besonderheiten soll bei diesem Import hingewiesen werden:

1. Zum einen wurde auf den Import von Synonymen verzichtet, da PostgreSQL keine Synonyme unterstützt (das Tool legt als Workaround Views an). In unserem Beispiel wurden nur die üblichen Synonyme von Oracle APEX exportiert, die für die Anwendung keine Rolle spielen.
2. Zum anderen wurden vor dem Laden der Daten die Constraints und Indizes deaktiviert. Die Daten werden nicht zwangsläufig gemäß der richtigen Reihenfolge (also erst die PK- und dann die FK-Datensätze) geladen). Bei aktivierten Constraints beim Import kann das zum Abbruch aufgrund der Verletzung der referentiellen Integrität führen. Die Constraints werden aber zum Schluss des Prozesses nachträglich aktiviert.

Fazit 

Das Werkzeug ora2pg ist ein nützlicher Helfer bei der Migration von Datenbanken von Oracle (oder MySQL) zu PostgreSQL. Es hilft initial bei der Analyse der Quellsysteme und verschafft einen ersten (!) Eindruck darüber, wie aufwändig eine Migration wohl werden kann. Dies hilft gerade bei großen Landschaften, wo hunderte oder tausende von Systemen betrachtet werden sollen. Auch beim eigentlichen Prozess (Schema- und Datenmigration) kann ora2pg sinnvoll unterstützen. Eine Betrachtung von ora2pg lohnt sich auf jeden Fall, wenn man sich mit einem solchen Migrationsvorhaben beschäftigt.

Sie haben Fragen zu PostgreSQL oder anderen Datenbanken? Dann sprechen Sie uns an!