Oracle ablösen — wenn es sich rechnet

Wir betreiben Oracle und PostgreSQL. Deshalb können wir Ihnen auch sagen, wann eine Migration sich nicht lohnt.

Der Wechsel von Oracle auf PostgreSQL spart Lizenz- und Supportkosten dauerhaft. Was er kostet, steht seltener fest — und genau daran scheitern Projekte: Die eingesparten Gebühren sind schnell ausgerechnet, der Aufwand für Portierung, Test und Umschaltung nicht. Wir ermitteln beide Seiten, bevor eine Entscheidung fällt.

PostgreSQL ist bei uns das Standardziel. MySQL und MariaDB setzen wir auf Wunsch ebenfalls um; für die Ablösung gewachsener Oracle-Anwendungen ist PostgreSQL in aller Regel die passendere Wahl, weil es prozeduraler Logik und den bekannten Oracle-Konstrukten deutlich näher kommt.

Der Kern unseres Vorgehensdreimal, nicht einmal

Durchlauf 1

Validierung der Technik und Verifikation der Funktionalität

Durchlauf 2

Migrationslaufzeiten, Abgleich gegen die Performance-Baselines, Gesamtleistung aller zugreifenden Anwendungen — und der Fallbackplan wird funktional durchgespielt

Durchlauf 3

die finale Migration — auf einem Weg, der zweimal vollständig geprobt wurde

Phase 1: Erstanalyse zum Festpreis

Der Einstieg ist unsere Kosten- und Lizenzanalyse zum Festpreis. Sie erhebt, was Ihre Datenbanken heute kosten, welche Optionen tatsächlich genutzt werden und wie die Verfügbarkeitsarchitektur aufgestellt ist. Daraus ergibt sich eines von zwei Ergebnissen: Entweder lohnt sich die Optimierung im Bestand — dann sagen wir das —, oder eine Migration kommt in Betracht. Nur im zweiten Fall folgt die vertiefende Analyse.

Phase 2: Vertiefende Analyse

Sie baut auf den Daten der Erstanalyse auf, statt sie noch einmal zu erheben.

Datenbank

Wir bewerten die Komplexität der Oracle-Datenbank: verwendete Datentypen, Größe der Tabellen, genutzte Oracle-Optionen und den Umfang sowie die Komplexität der vorhandenen PL/SQL-Objekte. Erfahrungsgemäß entscheidet nicht das Datenvolumen über den Aufwand, sondern der prozedurale Code — Schema und Daten sind vergleichsweise schnell umgezogen.

Dazu kommt der Workload der Instanzen: I/O-Verhalten, Wait Events und die Auslastung der Hardwareressourcen. Zusätzlich nehmen wir Baselines der ausgeführten SQL-Statements auf. Diese Baselines sind später das Maß, an dem die neue Plattform gemessen wird — ohne sie bleibt jeder Performancevergleich Behauptung.

Abhängige Anwendungen

Wir prüfen die Client-Zugriffe und die genutzten Verbindungen, um den Migrationsaufwand auf Seiten der Anwendungen, Schnittstellen und Anwender abzuschätzen. Diese Seite wird regelmäßig unterschätzt und ist häufig die größere Baustelle als die Datenbank selbst.

Infrastruktur

Wir betrachten die bestehende Oracle-Infrastruktur mit Active Data Guard, RAC-Installationen und GoldenGate-Replikationen, ebenso die eingesetzten Lizenzen. Für jede dieser Komponenten klären wir, ob sie fachlich getragen wird und wie sie auf der Zielplattform abgebildet wird.

Weiche Faktoren

Ebenso wichtig wie die Technik: Welche Datenbanktechnologie kann Ihr Haus intern sinnvoll unterstützen? Eine Migration, die das Betriebsteam nicht mitträgt, tauscht ein Lizenzproblem gegen ein Betriebsproblem. Diese Frage stellen wir früh und ehrlich.

Phase 3: Szenarien und kommerzielle Bewertung

Aus den erhobenen Fakten entwickeln wir mögliche Migrationsszenarien und bewerten sie kaufmännisch. Zwei Fragen stehen im Mittelpunkt:

Ist zusätzlich ein Umzug in eine Public Cloud sinnvoll — oder verschiebt er die Kosten nur von der Lizenz in den Betrieb?
Welche Kosten entstehen für die Migration selbst, und wie verhalten sich die Kosten auf der neuen Plattform im laufenden Betrieb?

Ergebnisoffen: „Bleiben und optimieren" ist ein legitimes Ergebnis dieser Bewertung. Wir verdienen an der Migration — deshalb sagen wir vorher, wann sie sich nicht rechnet. Umfangreiche PL/SQL-Logik im Kern der Anwendung, Standardsoftware mit Zertifizierung ausschließlich für Oracle oder ein Lastprofil, das tatsächlich RAC benötigt, sprechen dagegen.

Phase 4: Migration

Je nach Zielumgebung, Komplexität der Datenbank und Verfügbarkeitsanforderungen während der Umstellung kommen unterschiedliche Techniken zum Einsatz. Wir arbeiten unter anderem mit dem AWS Database Migration Service, mit ora2pg und mit oracle_fdw, dem Foreign Data Wrapper von PostgreSQL für Oracle.

Die Migration führen wir im Normalfall dreimal durch:

Durchlauf 1 — Technik und Funktion: Validierung des gewählten Verfahrens und Verifikation der Funktionalität. Hier zeigt sich, welche Konstrukte sich nicht automatisch übertragen lassen.
Durchlauf 2 — Laufzeit, Leistung und Rückfallebene: Test der Migrationslaufzeiten und Validierung der Migrationsperformance. Abgleich gegen die zuvor aufgenommenen Performance-Baselines der Datenbank sowie Bewertung der Gesamtleistung aller Anwendungen, die auf die Datenbank zugreifen. Im selben Durchlauf wird der Fallbackplan funktional durchgespielt — nicht beschrieben, sondern ausgeführt.
Durchlauf 3 — finale Migration: Die eigentliche Umstellung, auf einem Weg, der zu diesem Zeitpunkt zweimal vollständig geprobt wurde. Laufzeiten und Ergebnis sind dann keine Schätzung mehr.

Wie die Umschaltung selbst abläuft — Ausfallfenster, Reihenfolge, Zuständigkeiten, Abbruchkriterien — erarbeiten wir in einem Workshop mit allen Beteiligten. Eine Umstellung scheitert selten an der Technik und häufig daran, dass im entscheidenden Moment unklar ist, wer was entscheidet.

Phase 5: Betrieb auf der neuen Plattform

Nach der Migration betreiben wir PostgreSQL auf Wunsch weiter: Hochverfügbarkeit mit Patroni, Backup und Recovery mit pgBackRest, Betrieb im 7×24-Modell mit fest definierten SLAs. Wie das in der Praxis aussieht, zeigen unsere Referenzen — dort finden Sie auch das Projekt, in dem durch die Ablösung von Oracle 16 Prozessorlizenzen der Enterprise Edition frei wurden.

Damit endet die häufigste Sorge vor einer Migration: dass nach dem Wegfall des Oracle-Supports niemand mehr da ist, der die Plattform im Ernstfall kennt.