BEKOM OPEN PROOracle-Database-ExitPostgreSQL, EDB, MariaDB evaluieren
Oracle Database ablösen: PostgreSQL, EnterpriseDB, MariaDB, YugabyteDB im Vergleich, Migrationspfade und Entscheidungsmatrix für eine strukturierte Ablösung.
Warum Oracle-Database-Exit aktuell ist
Viele Organisationen prüfen ihre Oracle-Database-Abhängigkeit kritisch. Datenbanken sind die Betriebsgrundlage geschäftskritischer Anwendungen – ERP, CRM, Data-Warehouses und Fachverfahren hängen unmittelbar an der Plattform. Lizenzänderungen wirken damit auf Budget, Planbarkeit und Kontinuität des Betriebs. Auslöser sind strengere Lizenz-Audits (LMS-Reviews), Änderungen an CPU-Core-Faktoren und Named-User-Plus-Modellen, zusätzliche Java-SE-Subscription-Kosten sowie Lizenzbedingungen beim Cloud-Betrieb. Für IT-Leitung und Geschäftsführung stellt sich weniger die Frage, ob die Datenbankplattform langfristig Oracle bleibt, sondern wie eine strukturierte Evaluierung und – wenn sinnvoll – Ablösung geplant wird.
Oracle-Datenbanken sind das Fundament geschäftskritischer Anwendungen wie ERP-Systemen, CRM-Plattformen und Fachverfahren – deren Verfügbarkeit ist unmittelbare Betriebsvoraussetzung für die Auftragsverarbeitung. Lizenzänderungen und Audit-Risiken wirken direkt auf operative Geschäftsprozesse und regulatorische Compliance-Anforderungen, da auditfähige Dokumentation der Datenbanknutzung zwingend erforderlich ist. → BEKOM OPEN PRO Applications
Was sich bei Oracle-Lizenzen und Audits geändert hat
Die Rahmenbedingungen für Oracle-Kunden haben sich in den letzten Jahren deutlich verändert. Strengere Audit-Praktiken, zusätzliche Subscription-Modelle und geänderte Cloud-Bedingungen betreffen Organisationen jeder Größe.
Wesentliche Veränderungen:
Häufigere Lizenz-Audits (LMS-Reviews) mit Nachforderungen auf nicht korrekt lizenzierte CPU-Kerne oder Nutzer
Zusätzliche Java-SE-Subscription-Kosten seit 2023 auf Basis der Gesamt-Mitarbeiterzahl, nicht der tatsächlichen Nutzer
Restriktive Lizenzbedingungen beim Betrieb in nicht-autorisierten Public-Cloud-Umgebungen
Preisanpassungen bei Vertragsverlängerungen und Bündelung kostenpflichtiger Optionen wie Partitioning, Advanced Security oder RAC
Für Bestandskunden entstehen dadurch Planungsunsicherheiten, die eine strukturierte Strategie-Bewertung nahelegen – unabhängig davon, ob am Ende der Wechsel, die Anpassung oder der Verbleib steht.
Wann sich ein Oracle-Database-Exit-Assessment bei BEKOM rechnet
Wenn Audit-Nachforderungen, Renewal-Termine oder kostenpflichtige Optionen die Budget- und Risiko-Sicht ins Wanken bringen, ist eine strukturierte Bewertung der Optionen die nächste sinnvolle Stufe. BEKOM begleitet das Oracle-Exit-Assessment technologieneutral und ohne vorgegebenes Zielprodukt.
Typische Anlässe für ein Assessment:
Audit-Nachforderungen aus LMS-Reviews – Forderungen auf nicht korrekt lizenzierte CPU-Kerne, Named-User-Plus-Zähler oder unbeabsichtigt aktivierte Optionen mit deutlicher Budgetwirkung
Renewal-Stichtag mit erhöhter Forderung – Vertragsverlängerung mit Preissprung, Bündel-Anpassung oder Pflicht zur Übernahme weiterer Optionen
Kosten- oder Funktionsdebatte um Optionen – Partitioning, Advanced Compression, Advanced Security, RAC oder Active Data Guard werden hinterfragt, weil die produktive Nutzung schmaler ist als die lizenzierte Tiefe
Strategische Cloud- oder Plattform-Verschiebung – ERP-Modernisierung, Datenbank-Konsolidierung oder Verlagerung in den deutschen Datenraum stehen ohnehin an
Im Strategiegespräch werden Workload-Profile, Vertragslage und Migrationsfenster geklärt – das Ergebnis ist ein schriftliches Angebot mit dokumentiertem Bewertungsrahmen.
Compliance- und Audit-Druck als zusätzlicher Treiber
Oracle-Audit-Praxis, Java-SE-Subscription-Pflicht und Cloud-Lizenzbedingungen wirken nicht nur auf das IT-Budget, sondern auf die Audit- und Compliance-Position der Organisation. Branchen mit strenger Daten- oder Lizenz-Auskunftsfähigkeit bewerten Oracle damit zunehmend als strategisches Risiko.
Compliance-Treiber im Mittelstand:
LMS-Audit-Praxis und Beweislast – Lizenz-Auskunft muss innerhalb kurzer Fristen vorliegen, ohne strukturierte Inventur entstehen Audit-Risiken mit nachträglicher Forderung
Java-SE-Subscription nach Mitarbeiterzahl – seit 2023 wird Java SE nicht mehr nach tatsächlicher Nutzung, sondern nach Gesamt-Mitarbeiterzahl lizenziert; betrifft auch Java-Anwendungen ohne direkten Oracle-Datenbank-Bezug
Datensouveränität und US-CLOUD-Act – Branchen mit DSGVO-relevanten Datenbeständen (Kanzleien, Gesundheitswesen, Finanzdienstleister, Behörden) bewerten US-Anbieter-Bindungen zunehmend kritisch
Audit-Spuren für ISO 27001 und KRITIS – Lizenz-Bestände, Patch-Stände und Datenstandorte sind Bestandteil der Zertifizierungspflicht; Open-Source-Plattformen mit deutscher Sub-Auftragsverarbeiter-Liste sind hier nachweisleichter
Diese Treiber summieren sich zu einem dokumentierbaren Anlass, eine geordnete Bewertung der Oracle-Abhängigkeit anzustoßen – ohne damit das Ergebnis vorwegzunehmen.
Alternativen im Vergleich
Die Alternativen zu Oracle Database unterscheiden sich in Lizenzmodell, Kompatibilitätsgrad, Support-Landschaft und typischen Einsatzprofilen. Die folgende Übersicht bewertet die vier etablierten Optionen für mittelständische und gehobene Datenbank-Landschaften. Weiterführend: Datenbanken & Messaging.
PostgreSQL – Enterprise-Open-Source-RDBMS
PostgreSQL ist die in Europa am weitesten verbreitete Open-Source-Datenbank für anspruchsvolle Enterprise-Workloads. Sie unterstützt transaktionale Systeme, analytische Auswertungen, Geodaten und moderne Features wie JSONB und parallele Abfragen.
Charakteristika:
Lizenzmodell: Open Source (PostgreSQL-Lizenz, BSD-ähnlich), keinerlei kommerzielle Bindung
Feature-Abdeckung: ACID-Transaktionen, komplexe SQL-Konstrukte, Partitionierung, logische und physische Replikation, Point-in-Time-Recovery, Extensions (z. B. PostGIS, TimescaleDB)
Community und Support: sehr aktive weltweite Community, kommerzieller Support über Distributoren (EDB, Crunchy Data, Cybertec) oder spezialisierte Dienstleister
Typische Einsatzprofile: Mittelstand, ERP/CRM-Backends, Data-Warehouses mittlerer Größe, Eigenentwicklungen, Cloud-native Anwendungen
PostgreSQL ist für viele Oracle-Bestandskunden der pragmatische Nachfolger – die Feature-Breite deckt typische Oracle-Anforderungen ab, die Lizenzkosten entfallen bei der Community-Edition. Für PL/SQL-intensive Anwendungen ist eine Kompatibilitätsschicht zu prüfen.
EnterpriseDB (EDB) – PostgreSQL mit Oracle-Kompatibilität
EDB Postgres ist eine kommerzielle Distribution von PostgreSQL mit zusätzlicher Oracle-Kompatibilitätsschicht. Sie bildet viele Oracle-spezifische SQL-Konstrukte und PL/SQL-Pakete direkt nach und reduziert den Konvertierungsaufwand.
Charakteristika:
Lizenzmodell: kommerziell (Subscription), PostgreSQL-Kern als Open Source, Oracle-Kompatibilitäts-Module proprietär
Feature-Abdeckung: PostgreSQL-Funktionen plus EDB-Tools (Migration Toolkit, Enterprise Manager, Replication Server, Oracle-Kompatibilitätsschicht)
Community und Support: Herstellersupport direkt von EDB, Migrationsbegleitung und Tooling speziell für Oracle-Umstiege
Typische Einsatzprofile: Oracle-Migrationen mit hohem PL/SQL-Anteil, Anwendungen mit Oracle-spezifischen Konstrukten, hybride Umgebungen mit Oracle-Koexistenz
EDB ist die passende Wahl, wenn der Anteil an Oracle-spezifischem PL/SQL hoch und der Portierungsaufwand auf reines PostgreSQL zu groß wäre. Die Kompatibilitätsschicht reduziert den Code-Umbau, führt aber wieder eine Hersteller-Bindung ein – deutlich leichter gewichtig als Oracle selbst.
MariaDB – MySQL-Familie mit Enterprise-Features
MariaDB ist ein Community-getriebener Fork von MySQL mit eigenständiger Weiterentwicklung. Die Datenbank ist besonders in Web- und Anwendungs-Backends verbreitet und bietet eigene Enterprise-Funktionen.
Charakteristika:
Lizenzmodell: Open Source (GPL), kommerzielle MariaDB-Enterprise-Subscription optional
Feature-Abdeckung: ACID-Transaktionen, Replikation, Clustering (MariaDB Galera), Storage-Engines, kolumnare Erweiterungen (ColumnStore), teilweise Oracle-PL/SQL-Kompatibilität
Community und Support: aktive Community, kommerzieller Support über die MariaDB Corporation oder spezialisierte Dienstleister
Typische Einsatzprofile: Web-Anwendungen, Mittelstands-ERP-Backends mit MySQL-Historie, transaktionale OLTP-Systeme mit überschaubarer Komplexität
MariaDB ist die richtige Wahl bei bestehender MySQL-Kompatibilität oder Anforderungen, die stärker auf OLTP und Web-Backends ausgerichtet sind als auf analytische Oracle-Workloads.
YugabyteDB – verteiltes SQL der nächsten Generation
YugabyteDB ist eine verteilte SQL-Datenbank mit PostgreSQL-kompatibler Schnittstelle. Sie ist auf Skalierung, geografische Verteilung und hohe Ausfallsicherheit ausgelegt.
Charakteristika:
Lizenzmodell: Open Source (Apache 2.0 für den Kern), kommerzielle YugabyteDB-Enterprise-Optionen
Feature-Abdeckung: PostgreSQL-Wire-Kompatibilität, verteilte Transaktionen, automatisches Sharding, Multi-Region-Deployments, Ausfallsicherheit auf Knoten-Ebene
Community und Support: wachsende Community, kommerzieller Support über Yugabyte, Tooling für Betrieb und Monitoring
Typische Einsatzprofile: verteilte Anwendungen mit hohen Skalierungsanforderungen, Multi-Region-Szenarien, Cloud-native Anwendungen
YugabyteDB ist eine legitime Option für Organisationen, bei denen die Oracle-Ablösung mit einer Modernisierung zu verteilten Architekturen verbunden werden soll. Für klassische monolithische Oracle-Workloads ist PostgreSQL oder EDB meist die näher liegende Wahl.
Migrationspfad und Phasen
Eine Oracle-Ablösung ist ein anwendungsgebundener Umzug und verläuft anwendungsweise in vier aufeinander abgestimmten Arbeitsblöcken. Jede Stufe endet mit einem definierten Abnahmepunkt, den Geschäftsführung und Anwendungsverantwortliche vor dem nächsten Schritt zeichnen.
Phase 1: Schema-Inventar und Zielarchitektur
Die Oracle-Landschaft wird auf Schema- und Anwendungsebene erfasst: Tabellen, Indizes, Views, Constraints, Stored Procedures, Packages, Trigger, eingesetzte Optionen (Partitioning, Advanced Compression, Advanced Security, RAC) sowie Abhängigkeiten zu ETL-, Reporting- und Integrations-Ketten.
Inhalt der Phase:
PL/SQL-Inventar mit Konvertierungsindikator pro Objektklasse (automatisch portabel / prüfpflichtig / Neuimplementation)
Applikations-Mapping: Welches Frontend nutzt welches Schema, welche Session-Muster, welche Feature-Abhängigkeiten (z. B. Flashback, Materialized Views, Hierarchical Queries)
Bewertung der Ziel-Engines (PostgreSQL, EDB Postgres, MariaDB, YugabyteDB) entlang PL/SQL-Kompatibilität, Performance-Profil und Betriebsaufwand
Zielarchitektur, Migrationssequenz und Betriebsverantwortung
Ergebnis ist eine priorisierte Migrationsmatrix pro Anwendung plus dokumentiertes Zielbild. Die Pilotphase wird formell freigegeben.
Phase 2: Pilot-Konvertierung und Performance-Baseline
Eine fachlich repräsentative Anwendung wird vollständig auf die Zielplattform überführt, um die Werkzeugkette und das Laufzeitverhalten vor dem Roll-out abzusichern.
Inhalt der Phase:
Schema- und Code-Konvertierung mit ora2pg, EDB Migration Toolkit oder eigenen Skripten, abhängig vom Zielprodukt
Manuelle Nacharbeit bei Oracle-spezifischen Konstrukten (DBMS_-Pakete, AQ, Advanced Analytics, Hints)
Funktions-, Last- und Regressionstests mit Vergleich gegen die Oracle-Baseline (Antwortzeiten, Indexnutzung, Sperrverhalten)
Einbindung von Backup-Pfad, Monitoring-Agenten, Connection-Pooling und Reporting-Schnittstellen
Der Pilot liefert belastbare Aussagen zu Aufwandsverteilung, Performance-Abweichungen und notwendigem Hardening. Die Runbooks aus dieser Phase werden zur Vorlage für den produktiven Roll-out.
Phase 3: Migrations-Stufen nach Anwendungsgruppen
Der produktive Umstieg erfolgt anwendungsweise in Stufen, bis zum Cutover-Abnahmepunkt bleibt jede Stufe rückfallfähig.
Inhalt der Phase:
Stufen-Planung nach Kritikalität, Änderungsfenstern und fachlichen Abhängigkeiten (z. B. ETL-Taktung, Monats-/Jahresabschlüsse)
Cutover-Verfahren pro Stufe: Datensynchronisation, Testzeitfenster, Freigabekriterien, Fallback-Prozedur
Datenmigration über Dump/Import, logische Replikation (z. B. GoldenGate, BucardoSymmetric, EDB Replication Server) oder CDC-Werkzeuge
Parallelbetrieb: Oracle und Zielplattform liefern beide Daten, bis die Anwendungs-Stufe mit Abnahme übergeben ist
Kritische Produktions-Schemata folgen erst, nachdem weniger kritische Anwendungen den Prozess bestätigt haben.
Phase 4: Oracle-Stilllegung und Anwendungs-Übergabe
Nach der letzten Stufe wird die Oracle-Landschaft kontrolliert zurückgebaut und die neue Datenbankplattform als verbindliche Basis dokumentiert.
Inhalt der Phase:
Abnahme-Review pro Anwendung: Datenkonsistenz, Schnittstellen, Reports, Performance-Baselines
Stilllegung der Oracle-Instanzen, Anpassung von Support-Verträgen, Kündigung kostenpflichtiger Optionen zum Vertragsende
Aktualisierung von Betriebsdokumenten, Disaster-Recovery-Plänen, Backup-Konzepten
Wissenstransfer an das interne DBA-Team oder saubere Übergabe in den Managed Service
Mit dem Abschluss dieser Phase übernimmt der Regelbetrieb; die Migration endet mit dokumentiertem Betriebshandbuch und vereinbarter Service-Verantwortung.
Betriebsmodelle nach der Migration
Mit der Umstellung auf PostgreSQL, EDB, MariaDB oder YugabyteDB stellt sich die DBA-Frage neu. Drei Modelle decken die Bandbreite ab und lassen sich innerhalb der Vertragslaufzeit anpassen.
Internes Team
Die eigene DBA-Funktion bleibt verantwortlich für Design, Betrieb und Tuning der neuen Datenbank-Plattform.
Stärken:
Volle Hoheit über Tuning-Parameter, Index-Strategie und Patch-Zyklus
Kontinuierlicher Kompetenzaufbau auf PostgreSQL, EDB oder MariaDB direkt im Team
Unmittelbarer fachlicher Austausch mit Anwendungsentwicklung und Reporting
Kein Vertragspartner zwischen Entscheidung und Umsetzung
Geeignet, wenn:
- DBA-Erfahrung, SQL-Tuning und Backup/Recovery-Kompetenz belastbar abgedeckt sind
- Die Kapazität für 24/7-Bereitschaft und planbare Patch-Fenster intern vorhanden ist
- Datenbank-Entscheidungen bewusst im eigenen Haus liegen sollen
Managed Service durch BEKOM
BEKOM übernimmt den Datenbank-Betrieb mit vertraglich geregelten Leistungen: Monitoring, Patching, Backup, Restore-Tests, Performance-Tuning, Incident-Response und Notfall-Wiederanlauf. Strategie und Entwicklungs-Priorisierung bleiben beim Kunden.
Stärken:
Vertraglich definierte SLAs statt interner Eigenverantwortung
Direkter Zugriff auf Open-Source-Datenbank-Spezialisten ohne interne Einarbeitung
Entlastung bei nächtlichen Wartungen, Major-Version-Upgrades und Replikations-Tuning
Klar abgegrenzte Verantwortung zwischen Betrieb (BEKOM) und Produkt-Owner (Kunde)
Geeignet, wenn:
- Das interne Team auf Anwendungs- und Integrations-Themen konzentriert bleiben soll
- DBA-Themen Audit-, Compliance- oder Revisionsanforderungen erfüllen müssen
- Datenbanken mit hohem Verfügbarkeits- oder Transaktionsanspruch stabilisiert werden sollen
Hybrides Betriebsmodell
Betriebsaufgaben werden zwischen internem Team und BEKOM aufgeteilt. Architektur-, Release- und Change-Hoheit bleibt beim Kunden, bestimmte operative oder kritische Bereiche übernimmt BEKOM.
Stärken:
Kontrollierter DBA-Kompetenzaufbau im Team ohne Überlast
Bereitschaftsdienste, Replikations-Tuning oder HA-Designs extern abgedeckt
Aufgabenverteilung kann im Zeitverlauf mehr intern oder mehr extern werden
Dokumentierte Zusammenarbeit hält Wissen auch bei Fluktuation im Haus
Geeignet, wenn:
- DBA-Kompetenz im Team vorhanden, aber nicht breit genug abgedeckt ist
- Die Phase direkt nach Produktivsetzung mit externer Rückendeckung abgesichert werden soll
- Spezialthemen (Major-Upgrades, Replikations-Topologien, Backup-Strategien) punktuell extern laufen sollen
BEKOM ist Partner für den Oracle-Exit
Eine Oracle-Database-Ablösung ist ein anwendungsgetriebenes Projekt. Es kann intern, über einen Hyperscaler-DBaaS-Weg oder mit einem spezialisierten Dienstleister umgesetzt werden. Drei Merkmale prägen die Zusammenarbeit mit BEKOM: Bewertung ohne Lizenzinteresse, eine durchgehende technische Linie vom Schema-Inventar bis zum Betrieb, und ein konsequent am deutschen Mittelstand ausgerichteter Kommunikations- und Rechtsraum.
Unabhängige Bewertung ohne Lizenz-Interesse
BEKOM vertreibt weder PostgreSQL-, EDB-, MariaDB- noch Oracle-Lizenzen. Aus der Produktwahl entsteht keine Provision. Die Empfehlung richtet sich nach Schema-Komplexität, PL/SQL-Profil und Anwendungslandschaft, nicht nach Kanaltargets.
In der Projektrealität bedeutet das:
Bewertungsraster und Gewichtung (PL/SQL-Kompatibilität, Performance-Profil, Betriebsaufwand, Lizenz-Exposition) werden zu Projektbeginn schriftlich vereinbart
Empfehlungen werden gegen mindestens eine fundierte Alternative argumentiert
PostgreSQL, EDB, MariaDB und YugabyteDB laufen durch das gleiche Bewertungsraster
Ein begründeter Verbleib auf Oracle ist explizit ein zulässiges Ergebnis
Weder Subscription-Provisionen noch Partnertargets fließen in die Entscheidung ein
Methodik, Datenquellen und Tool-Ergebnisse (z. B. ora2pg-Report) sind offen dokumentiert
So entsteht eine Grundlage, die gegenüber Geschäftsführung, Aufsichtsorganen oder LMS-Auditoren belegbar ist – und bei Bedarf durch Dritte nachgeprüft werden kann.
Durchgängige technische Verantwortung
Vom ersten PL/SQL-Inventar bis zur Produktivsetzung arbeiten dieselben technischen Rollen. Der Informationsfluss zwischen Assessment, Pilot-Konvertierung und Stufenmigration läuft ohne Re-Briefing – Annahmen, Performance-Abweichungen und offene Risiken gehen nicht verloren.
Das heißt konkret:
Das Assessment-Team dokumentiert Annahmen, Risiken und offene PL/SQL-Punkte direkt im Übergabepaket an die Pilot-Phase
Ergebnisse aus der Pilot-Konvertierung (Treiber-Verhalten, Hot-Path-Performance, notwendige Hints) fließen ohne Umweg in die Stufe
Das Migrationsteam übergibt an den Betrieb mit gemeinsam erstelltem Runbook inkl. Tuning-Parameter und Baseline
Eine benannte technische Leitung begleitet das Projekt durchgängig von Schema-Analyse bis Produktivsetzung
Beratungs-, Migrations- und Betriebsrollen laufen unter einer einheitlichen Vertragsstruktur
Eskalations- und Abnahmewege sind über alle Phasen identisch und allen Beteiligten bekannt
Das senkt die Schnittstellenverluste, die bei Projektketten mit wechselnden Dienstleistern typisch sind – besonders im Datenbank-Kontext, wo Schema-Design, Anwendungsbindung und Betriebscharakteristik eng verzahnt sind.
Mittelständischer Rechts- und Kommunikationsrahmen
Vertragsgestaltung, Ansprechpartner und Betriebssprache sind auf deutschsprachige Organisationen ausgerichtet. Keine Eskalation an internationale Support-Tiers, keine Übersetzungsschleifen bei Vertragsfragen.
Im Alltag heißt das:
Vertrag, Service-Beschreibung und SLAs auf Deutsch, ohne englische Original-Klauseln mit Übersetzungsbeilage
Rechtsraum Deutschland, ohne Rückfall auf internationales Vertragsrecht bei Streitfällen
Ansprechpartner mit Erfahrung in mittelständischen DBA-Strukturen und Entscheidungsprozessen
Eskalationen erreichen verantwortliche Rollen ohne Zeitzonenverzug
Termine mit Geschäftsführung, Fachbereich oder Revision in gemeinsamer Arbeitssprache
Support- und Datenverarbeitung in Deutschland, ohne Weiterreichung an Offshore-Teams
Gegenüber Hyperscaler-DBaaS-Angeboten mit globalem Support-Modell und internationalen Systemhaus-Ketten ist dieser Rahmen ein belegbares Abgrenzungsmerkmal – besonders für Organisationen mit DSGVO-, Revisions- oder Branchen-Compliance-Anforderungen.
Kostenstruktur eines Oracle-Exits
Ein Oracle-Database-Exit wirkt auf drei Kostenebenen über den Lebenszyklus. Pauschale Einsparungen verspricht BEKOM nicht — ein strukturiertes Assessment ordnet die Ebenen gegen die heutige Ausgangslage und liefert eine belastbare Vergleichsgrundlage. Die tatsächliche Kostenwirkung hängt von Lizenz-Bestand, Optionen-Profil, Schema-Komplexität und Renewal-Terminen ab und wird pro Organisation ermittelt.
Bestandsseite – Oracle heute
Auf der Bestandsseite wirken nicht nur die Lizenz-Listenpreise, sondern auch Optionen-Bundles, Java-Subscriptions und Audit-Risiken. Ein vollständiger Vergleich erfasst alle vier Treiber statt nur den sichtbaren Lizenz-Anteil.
Kostentreiber im laufenden Oracle-Betrieb:
Lizenz- und Support-Kosten pro Core und Named-User-Plus – Listenpreise mit Wartungsanteil, jährliche Anpassungen und Bündel-Verschiebungen zwischen Editionen
Kostenpflichtige Optionen mit eigener Renewal-Logik – Partitioning, Advanced Security, Advanced Compression, RAC, Active Data Guard, Diagnostics und Tuning Pack
Java-SE-Subscription nach Gesamt-Mitarbeiterzahl – seit 2023 unabhängig von tatsächlicher Java-Nutzung, wirkt auf Anwendungen außerhalb der Datenbank
Audit-Risiko und Personalbindung – LMS-Reviews mit Nachforderungen, gebundene DBA-Stunden für Lizenz-Pflege, Audit-Vorbereitung und Reporting
Im Assessment werden diese Treiber gegen den heutigen Bestand gerechnet und ergeben die Bestandsseite des Vergleichs.
Migrationsphase – einmalige Aufwände
Während der Migration entstehen einmalige Aufwände, die als abgegrenzte Pakete vereinbart werden. Der Vorteil: jede Phase hat eigenen Umfang und eigene Abnahme — die Investitions-Entscheidung bleibt zwischen den Phasen reversibel.
Einmalige Migrations-Aufwände:
Schema- und PL/SQL-Inventar mit Konvertierungsindikator – pro Anwendung dokumentierter Konvertierungsaufwand (automatisch portabel / prüfpflichtig / Neuimplementation), Grundlage für Aufwandsschätzung
Pilot-Konvertierung mit Performance-Baseline – fachlich repräsentative Anwendung wird vollständig übertragen; Aufwand für Werkzeugkette, Testaufbau und Tuning
Stufen-Migration je Anwendungsgruppe – Schema-Migration, Code-Konvertierung, Funktions- und Last-Tests, Cutover und Hypercare pro Stufe
Parallel-Lizenzierung in der Übergangsphase – Oracle und Zielplattform laufen bis zur letzten Stufe parallel; Doppel-Kosten werden im Stufen-Plan berücksichtigt
Die Anteile werden im Angebot getrennt ausgewiesen, sodass interne Budgetbegründungen und spätere Vergleiche sauber möglich bleiben.
Zielseite – laufender Open-Source-Betrieb
Auf der Zielseite verschieben sich die Treiber von Lizenz- zu Plattform-Kosten. Der Lizenz-Anteil ist niedriger oder entfällt; dafür entstehen Kosten für Plattform-Betrieb, Speicher und optional Beratung.
Kostenebenen im laufenden Betrieb:
Monatliche Plattform-Service-Pauschale – abhängig von Anzahl Instanzen, HA-Topologie (Patroni-Cluster, EDB Failover Manager, Streaming-Replication), SLA-Stufe und Service-Modell (Fully Managed oder Co-Managed)
Speicher- und Backup-Kosten im deutschen Rechenzentrum – nach tatsächlichem Volumen, mit definierten Aufbewahrungs-Fristen je Datenklasse und protokollierten Restore-Tests
Optional kommerzielle Subscription für EDB oder Distributoren – wenn Oracle-Kompatibilitätsschicht (EDB Postgres) oder Distributor-Support (Crunchy Data, Cybertec) gewünscht ist, mit klarer Abgrenzung zur Community-Edition
Modular ergänzende Beratungs-Pakete – Schulungen, Tuning-Reviews, Major-Version-Upgrades und Compliance-Begleitung sind als getrennte Pakete buchbar, ohne in der monatlichen Pauschale zu wachsen
Pauschale Einsparungs-Versprechen vermeidet BEKOM bewusst — die belastbare Aussage entsteht erst aus dem Bestands-Vergleich des konkreten Falls.
Häufige Fragen zum Oracle-Database-Exit
Ist ein Oracle-Database-Exit für jede Organisation sinnvoll?
Nein. Landschaften mit tiefer Einbindung von Oracle E-Business Suite, Siebel, Exadata-Optimierungen oder komplexen RAC-Topologien können wirtschaftlicher bei Oracle bleiben, als einen Vollumstieg zu finanzieren. Die Entscheidung folgt aus dem Abgleich von Migrationsaufwand, zukünftiger Lizenz-Exposition und Abhängigkeitsprofil. Das Assessment liefert die belastbare Grundlage – das Ergebnis kann Vollmigration, Teil-Exit oder ein bewusst strukturierter Verbleib sein.
Wie unterscheiden sich PostgreSQL, EDB, MariaDB und YugabyteDB als Zielplattform?
PostgreSQL ist der breite Standard mit offener Community und kostenfreier Nutzung. EDB ergänzt Oracle-Kompatibilitätsschicht und Migrations-Toolchain, reduziert PL/SQL-Aufwand bei dichter Oracle-Bindung. MariaDB passt dort, wo die Anwendungslandschaft ohnehin MySQL-nah ist. YugabyteDB öffnet die Tür zu verteilten, Multi-Region-tauglichen Architekturen. Die Auswahl hängt von PL/SQL-Umfang, Workload-Profil und strategischer Ausrichtung ab.
Wie wird PL/SQL-Code auf die Zielplattform übertragen?
Automatisch portabler PL/SQL-Code (einfache Prozeduren, Cursor, Standard-SQL) wird mit ora2pg oder dem EDB Migration Toolkit nach PL/pgSQL übersetzt. Komplexere Konstrukte – DBMS_-Pakete, Autonomous Transactions, Oracle-Analytik-Funktionen, Hierarchical Queries – erfordern Nacharbeit oder Neuentwicklung. EDB reduziert diesen Aufwand spürbar über eine native Oracle-Kompatibilitätsschicht. Der Konvertierungsaufwand wird pro Anwendung im Assessment bewertet und dokumentiert.
Was geschieht mit Oracle-Optionen wie RAC, Partitioning oder Advanced Security?
Oracle-Optionen werden nicht 1:1 abgebildet, sondern durch native Mechanismen der Zielplattform ersetzt. Partitioning gibt es in PostgreSQL ab Version 10 nativ, logische Replikation ersetzt viele Streams-Szenarien, Hochverfügbarkeits-Cluster werden mit Patroni, repmgr oder EDB Failover Manager aufgebaut. Advanced-Security-Funktionen (TDE, Data Redaction) werden über PostgreSQL-Extensions, Storage-Verschlüsselung oder Anwendungs-Layer gelöst. Jede Option wird einzeln geprüft.
Kann die Oracle-Datenbank und die Zielplattform parallel laufen?
Ja, der Parallelbetrieb ist Teil des Migrations-Konzepts. Während der Stufenmigration existieren Oracle und Zielplattform nebeneinander; Daten werden über Dump/Import, logische Replikation oder Change-Data-Capture-Werkzeuge synchronisiert. Jede Anwendung wechselt innerhalb eines Cutover-Fensters und bleibt bis zur Abnahme rückfallfähig. Die Koexistenz wird bis zur letzten migrierten Anwendung geplant, inklusive ETL-, Reporting- und Schnittstellen-Konsistenz.
Wie läuft ein bestehender Oracle-Vertrag während der Migration weiter?
Laufende Oracle-Verträge gelten bis zum Ablauf und werden bis zur Stilllegung jeder Anwendung weiter genutzt. Der Migrationsfahrplan wird üblicherweise so gelegt, dass die Außerbetriebnahme vor der nächsten Vertragsverlängerung abgeschlossen ist. Kündigung von Support-Verträgen oder kostenpflichtigen Optionen erfolgt erst nach Nachweis der Stilllegung. Lizenzrechtliche Spezialthemen – Nutzungsaudit, Second-Hand-Optionen, Partial-Termination – werden vor der ersten Stufe geklärt.
Welche Rolle spielt das interne DBA-Team im Migrationsprojekt?
Das DBA-Team ist durchgehend beteiligt. In Phase 1 liefert es PL/SQL-Kenntnisse, Anwendungslandkarte und bekannte Performance-Eigenheiten. In Phase 2 erfolgt die Hands-on-Erprobung der Zielwerkzeuge gemeinsam. In Phase 3 wird die Aufgabenverteilung pro Stufe vertraglich fixiert. Das Zielbetriebsmodell wird mit dem DBA-Kompetenzprofil abgestimmt, sodass nach Produktivsetzung weder Überforderung noch Leerlauf entstehen.
Welche Risiken gibt es rund um Performance und Isolation Levels?
Unterschiedliche Optimizer, andere Default-Isolation-Levels (Oracle: Read Committed mit MVCC, PostgreSQL: gleich, aber mit abweichendem Locking-Verhalten), abweichende Index-Nutzung und fehlende Hints sind typische Befunde. Der Pilot liefert eine Performance-Baseline vs. Oracle – Abweichungen werden durch Index-Tuning, Query-Rewrite oder Statistik-Anpassung adressiert. Kritisch sind Rollback-tolerante Stapelverarbeitung und Anwendungen mit sehr kurzen Antwortzeit-SLAs; sie erhalten im Pilot besondere Aufmerksamkeit.
Was kostet das Oracle-Exit-Assessment bei BEKOM?
Das Assessment ist ein eigenständig beauftragtes Beratungsprojekt. Der Aufwand richtet sich nach Anzahl der Schemata, Umfang des PL/SQL-Bestands, Integrationstiefe (ETL, Reporting, Applikationsbindung) und gewünschtem Detailgrad. Dem Auftrag geht ein unverbindliches Strategiegespräch voraus, in dem Umfang und Abgrenzung definiert werden. Daraus entsteht ein schriftliches Angebot mit Phasenlogik, Abnahmekriterien und pro Phase ausgewiesenen Leistungen.
Kann BEKOM den Betrieb der bestehenden Oracle-Umgebung übernehmen, wenn wir vorerst bleiben?
Ja. Wenn das Assessment zeigt, dass ein Verbleib auf Oracle wirtschaftlich sinnvoll ist, übernimmt BEKOM den Betrieb als Managed Service – mit Monitoring, Patch-Zyklen, Backup, Performance-Tuning und SLA-Rahmen. Die Bewertung ist technologie-neutral: Es gibt keine vertriebliche Motivation für einen Wechsel, wenn die Daten ihn nicht begründen. Ein späterer Teil-Exit lässt sich aus einem laufenden Managed-Service-Verhältnis strukturiert vorbereiten.
Nächster Schritt: Oracle-Exit-Evaluierung
Den Einstieg bildet ein Strategiegespräch zur aktuellen Oracle-Landschaft, realistischen Zielplattformen und passender Umsetzungsform. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus; ein schriftliches Angebot für das Assessment entsteht erst nach gemeinsamer Abgrenzung von Umfang und Zielbild.
BEKOM liefert eine strukturierte Bestandsaufnahme der Oracle-Database-Landschaft mit konkreten Empfehlungen für PostgreSQL, EDB oder MariaDB als Zielplattformen. Das Assessment umfasst eine detaillierte Architektur-Empfehlung mit Service-Design für die Migration sowie Klarheit über den notwendigen Betriebsumfang der neuen Datenbankplattform. Sie erhalten einen vollständigen Überblick über technische Abhängigkeiten, Migrationsaufwände und den Betrieb der Ziel-Datenbank.
Strategiegespräch vereinbaren
Im Strategiegespräch klären BEKOM-Spezialisten mit DBA- und Anwendungsverantwortlichen die Ausgangslage: Schema-Komplexität, Anwendungsbindung, PL/SQL-Profil und realistische Zielkandidaten. Das Ergebnis ist eine erste fachliche Einordnung – ergebnisoffen und ohne vorfestgelegte Zielplattform.
Strukturiertes Assessment durchführen
Im Assessment entstehen Schema- und PL/SQL-Inventar (unter anderem auf Basis eines ora2pg-Reports), Anwendungslandkarte, belegte Alternativen-Bewertung und das dokumentierte Zielbild. Die Entscheidungsvorlage enthält begründete Empfehlung, Risikoliste, Aufwandsschätzung pro Anwendung und einen Phasenplan.
Pilot-Konvertierung und Stufenmigration begleiten
Nach Freigabe begleitet BEKOM die Umsetzung: Pilot-Konvertierung einer Referenzanwendung, Performance-Baseline-Vergleich, Stufenmigration mit Parallelbetrieb und Rückfall-Optionen bis zur dokumentierten Übergabe. Die Beteiligungsform reicht von Beratung über Projektpartnerschaft bis zur vollständig übernommenen Migrationsdurchführung.