oracle-consulting.de

Was Ihre Datenbanken wirklich kosten

Wir verkaufen keine Lizenzen. Wir rechnen nach, welcher Weg am Ende günstiger ist — einschließlich der Kosten, die in keinem Angebot stehen.

Oracle-Lizenzen sind für viele Unternehmen der größte einzelne Posten im IT-Budget, und die Supportgebühr von 22 Prozent des Lizenzwerts fällt Jahr für Jahr erneut an. Gleichzeitig ist selten klar, wofür genau gezahlt wird: welche Optionen tatsächlich gebraucht werden, welche versehentlich aktiviert wurden, und ob die gewählte Edition zum tatsächlichen Bedarf passt.

Wir gehen diese Fragen der Reihe nach durch — technisch, nicht kaufmännisch. Am Ende steht eine Zahl, die Sie Ihrer Geschäftsführung vorlegen können, und ein Weg dorthin, den wir auch umsetzen können.

Werden alle als genutzt gemeldeten Features tatsächlich gebraucht?

Oracle protokolliert in DBA_FEATURE_USAGE_STATISTICS, welche Optionen in einer Datenbank verwendet wurden. Dieselbe View liest auch das Prüfskript, das bei einem Lizenzaudit zum Einsatz kommt. Erfahrungsgemäß stehen dort Einträge, mit denen niemand im Haus gerechnet hat.

Typische Fälle, die wir immer wieder finden:

  • Ein einziger Klick auf die Performance-Seite im Enterprise Manager, ein einziger Aufruf einer AWR-View — und das Diagnostic Pack gilt als genutzt. Über den Parameter control_management_pack_access lässt sich das gezielt unterbinden.
  • Eine partitionierte Tabelle, die ein Entwickler vor Jahren angelegt hat, aktiviert die Option Partitioning für die gesamte Datenbank.
  • inmemory_size steht auf einem Wert größer null, obwohl niemand die In-Memory-Option nutzt.
  • Eine einzelne verschlüsselte Spalte zieht Advanced Security nach sich, eine einzelne komprimierte Tabelle Advanced Compression.
  • Eine Spalte vom Typ SDO_GEOMETRY in einem Fremdprodukt aktiviert Spatial.

Für jeden Fund klären wir dieselben drei Fragen: Wird die Option fachlich gebraucht? Wenn nicht — lässt sie sich sauber zurückbauen, und wie sieht der Weg dorthin aus? Wenn ja — ist sie korrekt lizenziert? Das Ergebnis ist entweder eine Einsparung oder die belegte Gewissheit, dass die Lizenzierung stimmt. Beides ist ein guter Ausgang.

Ist der Wechsel von Enterprise auf Standard Edition 2 sinnvoll?

Der Preisunterschied ist erheblich: Die Enterprise Edition wird pro Prozessor unter Anwendung des Core-Faktors lizenziert, die Standard Edition 2 dagegen pro belegtem Sockel — und zwar unabhängig davon, wie viele Kerne darin stecken. Bei den heute üblichen Kernzahlen pro Sockel verschiebt das die Rechnung deutlich.

Dafür gibt es Grenzen, die man vorher kennen muss. Die Standard Edition 2 läuft nur auf Servern mit höchstens zwei belegten Sockeln und begrenzt jede Instanz auf 16 CPU-Threads. Seit Oracle 19c ist RAC in der Standard Edition nicht mehr enthalten; an seine Stelle ist ab Release Update 19.7 Standard Edition High Availability getreten, das eine Einzelinstanz auf gemeinsamem Speicher zwischen zwei Knoten umschaltet — mit Wiederanlaufzeiten im Minutenbereich statt im Sekundenbereich.

Ebenfalls entfallen: Partitioning, Parallel Query, Data Guard, Advanced Compression, In-Memory sowie das Diagnostic und Tuning Pack samt AWR. Für die Performanceanalyse tritt Statspack an dessen Stelle, was in der Praxis gut funktioniert, aber Umgewöhnung bedeutet.

Die entscheidende Frage: Trägt eine dieser Funktionen Ihre Anwendung, oder wurde sie nur mitgenommen, weil sie in der Enterprise Edition ohnehin dabei war? Bei Partitionierung ist die Antwort oft „sie trägt" — dann scheidet der Wechsel aus. Bei Parallel Query und Compression lohnt sich das genaue Hinsehen.

Lohnt sich eine Migration nach PostgreSQL — inklusive der Migrationskosten?

Diese Frage wird oft nur von einer Seite gerechnet. Die eingesparten Lizenz- und Supportgebühren stehen schnell fest, der Aufwand für den Umstieg dagegen selten. Wir stellen beides gegenüber und nennen den Zeitpunkt, ab dem sich die Umstellung amortisiert.

Auf der Aufwandsseite betrachten wir:

  • die Portierung von PL/SQL — Packages gibt es in PostgreSQL nicht, Oracle-spezifische Funktionen müssen ersetzt werden; Werkzeuge wie ora2pg nehmen einen Teil ab, manuelle Nacharbeit bleibt
  • die Applikationsschicht, die erfahrungsgemäß die größere Baustelle ist als die Datenbank selbst: SQL mit Oracle-spezifischer Syntax, abweichendes Verhalten bei DATE, bei leeren Zeichenketten und bei der Sortierreihenfolge
  • Testaufwand und Parallelbetrieb während der Umstellung
  • den Aufbau von Hochverfügbarkeit und Backup auf der neuen Plattform
  • Einarbeitung des Betriebspersonals und ein etwaiger Supportvertrag

Es gibt Fälle, in denen wir abraten: umfangreiche PL/SQL-Logik, die den Kern der Anwendung bildet; Standardsoftware, die nur für Oracle zertifiziert ist; Lastprofile, die tatsächlich RAC benötigen. Ein ehrliches „lohnt sich nicht" ist ein legitimes Ergebnis dieser Analyse.

Wo es sich lohnt, haben wir es gemacht: In einem Konzernprojekt wurden durch die Ablösung von Oracle mit PostgreSQL 16 Prozessorlizenzen der Enterprise Edition frei — bei Core-Faktor 0,5 entspricht das 32 Intel-Cores, die nicht länger lizenziert und supportet werden müssen. Weitere Beispiele finden Sie unter Referenzen.

Wie plane ich eine ausfallfreie Architektur, ohne die Kosten zu treiben?

Hochverfügbarkeit wird häufig gekauft, bevor die Anforderung feststeht. Wir beginnen deshalb mit zwei Zahlen: Wie lange darf ein Ausfall dauern, und wie viele Minuten an Daten dürfen dabei verloren gehen? Erst danach lässt sich sagen, welche Architektur nötig ist — und welche schlicht zu teuer wäre.

Die Stufen unterscheiden sich in Kosten und in Wiederanlaufzeit erheblich:

RMAN, Backup und Restore
Lizenzfrei, in jeder Edition enthalten. Wiederanlauf in Stunden. Für viele Systeme ausreichend, wenn das Backup regelmäßig auch tatsächlich zurückgespielt und geprüft wird.
Standby-Datenbank
In der Enterprise Edition über Data Guard, in der Standard Edition 2 über eigene Skripte oder ein Fremdprodukt. Wiederanlauf in Minuten, Datenverlust nahe null.
Standard Edition High Availability
Ab 19.7 in der Standard Edition 2 enthalten. Umschaltung einer Einzelinstanz zwischen zwei Knoten auf gemeinsamem Speicher, ohne Zusatzlizenz.
Active Data Guard
Erlaubt Lesezugriff auf der Standby-Datenbank — eine kostenpflichtige Zusatzoption. Wer nur ausfallsicher sein will und nicht auf dem Standby liest, braucht sie nicht.
Real Application Clusters
Aktiv-aktiv, Wiederanlauf in Sekunden — und die teuerste Stufe, da die Option zusätzlich zur Enterprise Edition pro Prozessor lizenziert wird.

Was wir häufig sehen: Ein Cluster wurde vor Jahren für Ausfallsicherheit beschafft, nicht für Skalierung. Für diese Anforderung hätte eine Standby-Lösung genügt — zu einem Bruchteil der Kosten. Beachtenswert ist außerdem die Failover-Regel im Oracle-Lizenzhandbuch, nach der ein passiver Knoten unter bestimmten Bedingungen für eine begrenzte Anzahl von Tagen im Jahr unlizenziert einspringen darf.

Erstanalyse zum Festpreis

Den Einstieg bieten wir als abgegrenztes Paket zum Festpreis an. Sie wissen vorher, was es kostet und was Sie bekommen.

ErstanalyseFestpreis
899 €
pro Einzelinstanz, zzgl. MwSt. — für den unten beschriebenen Umfang, einschließlich Bericht und Auswertungsgespräch.
Größere Landschaft
Bei mehreren Instanzen oder bei RAC- und Data-Guard-Umgebungen nennen wir nach einem kurzen Gespräch einen Festpreis für die gesamte Landschaft. Dieser liegt in aller Regel unter der Summe der Einzelanalysen, weil sich Skripte und Auswertung wiederverwenden lassen.
Was wir uns ansehen
Feature- und Optionsnutzung je Datenbank, Abgleich mit Ihrem Lizenzbestand, Bewertung eines Editionswechsels, Wirtschaftlichkeitsrechnung für eine Ablösung durch PostgreSQL, Bewertung der bestehenden Verfügbarkeitsarchitektur gegen Ihre tatsächlichen Anforderungen.
Was Sie erhalten
Einen schriftlichen Bericht mit Befunden je Datenbank, einer nach Einsparpotenzial priorisierten Empfehlung und einer Aufwandsschätzung für jede Maßnahme. Dazu ein Gespräch, in dem wir den Bericht mit Ihnen durchgehen.
Was wir dafür brauchen
Lesenden Zugriff auf die betroffenen Datenbanken oder die Ausgabe unserer Skripte, Ihren aktuellen Lizenz- und Supportbestand sowie ein kurzes Gespräch über die Verfügbarkeitsanforderungen der betroffenen Anwendungen.
Was danach passiert
Nichts, wenn Sie das so wollen — der Bericht gehört Ihnen und ist auch ohne uns umsetzbar. Wenn Sie möchten, setzen wir die Maßnahmen um.

Zur Einordnung: Wir sind weder Lizenzhändler noch Rechtsberatung. Wir bewerten die technische Nutzung Ihrer Datenbanken und rechnen die Alternativen durch. Verhandlungen mit Oracle und die rechtliche Würdigung von Verträgen gehören nicht dazu — wir liefern Ihnen aber die Faktenlage, auf der beides aufsetzt.

Sprechen Sie uns an: Kontakt