In der Welt der Datenbanken hat sich Oracle seit langem zurecht als feste Größe etabliert. Seine leistungsstarken Funktionen und umfangreichen Möglichkeiten haben Unternehmen weltweit dazu veranlasst, auf Oracle als ihre bevorzugte Datenbanklösung zu setzen.
Neben kommerziellen Datenbanksystemen gibt es aber auch noch Open Source Lösungen wie PostgreSQL, die für so manchen Einsatzzweck vielleicht eine ausreichende und finanziell reizvolle Alternative darstellen können. Doch welche Aspekte sind zu berücksichtigen, wenn man eine bestehende Lösung auf eine andere Datenbank Technologie migrieren möchte?
Welche Punkte sollten im Voraus bewertet werden, um solche strategischen Entscheidungen treffen zu können? In diesem Blogbeitrag beschreiben wir am Beispiel Oracle auf PostgreSQL allgemeine Faktoren, die zur Entscheidungsfindung beachtet werden sollten.
Wenn man eine Oracle Datenbank auf PostgreSQL umstellt, darf man nicht ausschließlich die Objekte und PL/SQL Stored Procedures betrachten, die in der Datenbank liegen. Es muss genauso jedes System betrachtet werden, das auf die Oracle Datenbank zugreift.
Gibt es z.B. eine Software, die Ihre Daten in der Oracle Datenbank ablegt, muss geprüft werden, ob diese auch mit PostgreSQL als Datenbank unterstützt wird. Diese Software könnte eine Windows-Client-Applikation, eine Java-Multi-Tier-Applikation, eine php-Webapplikation oder auch eine Javascript Applikation sein. Selbst wenn die Software out of the box PostgreSQL unterstützt, darf man auf die Datenmigration nicht vergessen.
Gibt es andere Datenbanken, die mit Database Links auf diese Daten zugreifen, müssen dort z.B. entsprechende ODBC Gateways verwendet werden, um weiter zugreifen zu können. Auch dann müssen vielleicht noch zusätzlich die Statements, die abgesetzt werden, angepasst werden, da die Syntax nicht vollständig ident ist oder vielleicht Funktionen verwendet werden, die nicht verfügbar sind.
Zusammengefasst bedeutet das, dass man die gesamte Architektur, in die die umzustellende Datenbank eingebettet ist, zusätzlich zu der Migration der Datenbank betrachten, und die Umstellungsmöglichkeiten rundherum prüfen und bewerten muss.
In der Datenbank selbst müssen Tabellen, Views, Materialized Views, Database Links bewertet werden. Besondere Aufmerksamkeit brauchen aber meist PL/SQL Stored Procedures/Functions und Packages. Da es in der PostgreSQL Datenbank z.B. keine Packages gibt, müssen diese Objekte meist mit hohem manuellen Aufwand umgestellt werden. Weiters fehlen BuiltIn-Packages und Dictionary Views, die man in der Oracle Datenbank vielleicht verwendet hat.
Was ist aber jetzt mit dem Advanced Server von EnterpriseDB? Diese Datenbank soll ja fast wie eine Oracle Datenbank wirken?
EDB Advanced Server ist im Kern eine PostgreSQL Datenbank mit div. kommerziellen Erweiterungen und Anpassungen von EnterpriseDB. Dadurch ist der Kompatibilitätsgrad höher als mit einer reinen PostgreSQL Datenbank. Ein sehr wichtiger Bestandteil dieser Erweiterung ist die SPL (Structured Program Language), das PL/SQL Packages erlaubt. EDB Advanced Server enthält auch nachgebaute Oracle-BuiltIn Packages. Dadurch ist der Adaptierungsaufwand für PL/SQL Stored Procedures/Functions und Packages stark reduziert. Auch SQL-Funktionen und Datentypen, die in einer reinen PostgreSQL Datenbank nicht mit Oracle ident sind, stehen hier zur Verfügung. Auch hier ist der Kompatibilitätsgrad höher und somit die Umstellungsaufwände geringer.
Das heißt aber der Unterschied im Umstellungsaufwand auf reines PostgreSQL oder auf EDB Advanced Server hängt stark von obigen Faktoren ab (z.B. wie viel PL/SQL im Einsatz ist).
Roland ist Leiter unserer Development Abteilung.
