Oracle Datenbank Lizenzierungsmetriken SE2 versus EE

updated on

Bei der Oracle Datenbank gibt es mehrere verschiedene Editionen mit unterschiedlichen Lizenzierungskriterien:

  • Oracle XE (bis 18c) und Oracle Free (ab 23ai) sind kostenlos nutzbar
  • Oracle Standard Edition bzw. Standard Edition One bis Oracle 11gR2.
  • Oracle Standard Edition 2 ab Oracle 12.1.0.2
  • Oracle Enterprise Edition (seit ca. Oracle 8)
  • Oracle Personal Edition (seit ca. Oracle 8) ist für Nutzung am Notebook gedacht und nur für Named User verfügbar

Da zum Zeitpunkt der Erstellung des Artikels nur zwei kostenpflichtige Editionen relevant (supported) sind, bezieht sich dieser Artikel lediglich auf die Standard Edition 2 (kurz: SE2) und die Enterprise Edition (EE).

Für die SE2 und EE gibt es mehrere grundsätzliche Lizenzierungsarten:

  • Names User Plus (NUP): hier werden die Benutzer der Datenbank gezählt (ähnlich User Lizenzierung bei Microsoft), wobei auch hier einige Regeln zu befolgen sind. Darauf gehen wir in diesem Artikel allerdings nicht ein.
  • Prozessor / CPU: hier erfolgt eine Lizenzierung basierend auf den eingesetzten CPUs – Rechnereinheiten. Auf dieses Thema gehen wir in diesem Artikel genauer ein.

Auch weitere Sonderfälle wie Personal Edition Lizenzierung, Embedded Lizenzen, etc. oder spezielle Rahmenverträge wie ULA, PULA, etc. werden hier nicht berücksichtigt.

Zusätzlich ist zu beachten, dass Oracle bei der Datenbank Lizenzierung noch spezielle Regeln bezüglich dem Einsatz zwischen on-Premise (im eigenen Rechenzentrum) und Cloud Anbieter unterscheidet. Auch ob und welche Art von Virtualisierung genutzt wird, oder welche CPUs eingesetzt werden, hat einen Einfluss auf die Lizenzierung.

Referenzen:

Oracle Datenbank Standard Edition 2

Die SE2 wurde mit der Datenbank Release 12.1.0.2 ab dem 1. Sepember 2015 eingeführt – siehe auch: Änderungen bei der Oracle Datenbank Standard Edition Lizensierung. Zu diesem Zeitpunkt war es noch möglich die SE2 Datenbank als Real Application Cluster zu betreiben. Beginnend mit Oracle 19c ist das nicht mehr möglich – siehe: Artikel SE2 ohne RAC!. Für die Standard Edition gibt es auch keine kostenpflichtigen Optionen oder Management Packs – diese sind der Enterprise Edition vorbehalten. Seit einigen Jahren, gibt es jedoch kostenlose Optionen, beispielsweise – Machine Learning, Spatial und Multitenant (mit Limitationen und abhängig von der Oracle Version) 12c und 18c bzw. ab 19c.

Aktuell – Juli 2025 – gelten folgende Kriterien:

  • Es dürfen nur noch Server mit maximal 2 CPU-Sockeln eingesetzt werden. Der Server darf nicht mehr als zwei physische CPU Sockel enthalten. Pro bestückten Sockel ist eine SE2 Prozessor Lizenz notwendig.
  • Die maximale Anzahl der nutzbaren CPU Threads ist auf 16 je Datenbank Instanz limitiert, wobei der Server mehr CPU Threads/Cores haben darf – diese werden aber nicht genutzt.

Diese Kriterien hören sich zwar einfach und konkret an, wären da nicht die vielen – teilweise komplexen – Definitionen und Einschränkungen, auf die jetzt im Detail eingegangen wird.

Definition CPU Sockel für SE2 on-Premise

Die Definition des CPU Sockels ist insofern kompliziert, dass Oracle in den Lizenzbedingungen an verschiedenen Stellen wahlweise von multi-chip bzw. chiplets spricht, die für die Berechnung relevant sind. Aktuelle CPUs wie Intel® Xeon® und AMD EPYC™ bestehen intern aus mehreren Teilen (chips/dies/chiplets), die auf einem gemeinsamen Träger verbaut sind. Für die Berechnung werden jene Teile herangezogen, die CPU Cores / Recheneinheiten enthalten. Damit das Ganze noch komplizierter wird, findet man diese Information auf den Seiten der Hersteller nicht so einfach und klar beschrieben.

Eine mögliche Quelle für diese Information findet man beispielsweise bei Wikipedia – AMD Zen4 in den Tabellen als CCD Chiplets. Selbst hier muss man die angegebenen Informationen noch entsprechend interpretieren:

Die AMD EPYC™ 9174F CPU mit 16 Cores (32 Threads) wird in der Tabelle mit 8 CCDs angeführt, weil der Träger Platz für 8 CPU Chipslets hat. Allerdings werden jeweils nur so viele CPU Chiplets auf den Träger verbaut, wie benötigt. Etwas weiter unten in der Tabelle sieht man, dass bei allen CPUs bis zu 64 Cores immer 8 CCDs angeführt sind. Somit kann man ausrechnen, dass ein CCD jeweils 8 Cores enthalten muss (64 Cores / 8 CCDs). Da diese CPU über 16 Cores verfügt, werden somit 2 CCDs genutzt. Diese CPU ist für eine Oracle Standard Edition 2 einsetzbar, sofern der Server nur einen physischen Sockel aufweist. Da für jeden Sockel – in diesem Fall CCDs – eine CPU Lizenz notwendig ist, braucht man somit 2 Oracle SE2 Lizenzen für einen Server mit dieser CPU.

Referenzen:

  • Oracle Software Licensing Basics auf Seite 13:
    For multi-chip module processors, each chip on the processor counts as one occupied socket
  • Licensing Information User Manual – in den Absatz über About License Options for Oracle Database Standard Edition 2 on Oracle Database Appliance (der eine Ausnahme für die ODA definiert):
    …For the purposes of licensing Oracle Database Standard Edition 2 on Oracle Database Appliance running multi-chip modules, where each chip in a multi-chip module is counted as an occupied socket for licensing purposes, you may exceed the 2 sockets per server limit…

Definition CPU Sockel für SE2 in Authorized Cloud Environments

Da man in der Cloud keinerlei Möglichkeit hat, die verwendete CPU als Basis für die Lizenzierung zu nutzen, geht Oracle hier einen anderen Weg. Es gibt eine Liste von anerkanten Cloud Anbietern – aktuell sind neben der eigenen Oracle Cloud folgende Angebote akzeptiert: Amazon Web Services – Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS), Microsoft Azure Platform and Google Cloud Platform (GCP).

Oracle definiert einen CPU Sockel bei einem Authorized Cloud Vendor mit 4 vCPUs. Somit benötigt man für einen VM mit bis zu 4 vCPUs eine Prozessor Lizenz und für 8 vCPUs entsprechend zwei Prozessor Lizenzen der SE2. Mehr als 8 vCPUs sind nicht möglich/erlaubt.

Abhängig von der vom Cloud Anbieter genutzten CPU bekommt man deutlich weniger Rechenleistung als erwartet. Je nach der für das Angebot genutzten CPU kann es sein, dass man in Wirklichkeit nur 2 echte Cores pro Prozessor Lizenz bekommt. Der Grund ist, dass bei den meisten Angeboten Intel CPUs mit aktivem Hyperthreading (virtuelle Cores) bzw. bei AMD CPUs SMT (Symetric Multi Threading – ein Core sind dann 2 Threads) genutzt wird. In diesem Fall sieht man in der VM eben 2 vCPUs, auch wenn dahinter nur ein Core steht!

Zusätzlich setzen die Cloud Provider auf CPUs mit vielen Cores, die dann im Betrieb deutlich niedriger getaktet sind, als man dies on-Premise typischerweise vorfinden würde. Die meisten von den großen Cloud Anbieter genutzten CPUs weisen nur eine Taktrate von 2.2 bis 2.5GHz auf. Eine AMD EPYC™ 9174F hingegen hat eine Mindesttaktrate von 4.1GHz – was (fast) der doppelten Rechenleistung im Vergleich zu dem Cloud Anbieter Angebot entspricht!

Referenzen:

Oracle Datenbank Enterprise Edition

Die Berechnung der benötigten Lizenzen basiert auf den ECHTEN CPU Cores, die auf dem physischen Server, auf dem die Oracle Enterprise Edition Datenbank läuft, vorhanden sind.

Intel Hyperthreading oder SMT – Symetrisches Multithreading – werden dabei nicht berücksichtigt. Damit man nicht alle physischen Cores eines Servers lizenzieren muss, gibt es die Möglichkeit durch „Partitioning“ der Hardware diese Anzahl zu reduzieren. Allerdings gibt es seitens Oracle hierzu einige Einschränkungen, welche Technologien in diesem Zusammenhang akzeptiert werden und welche nicht. Mehr Details zu dem Thema findet man im Oracle Partitioning Policy Guide.

Es gibt noch einen weiteren Faktor, der die benötigten Lizenzen beeinflusst. Abhängig von der eingesetzten CPU gibt es einen Core Faktor, der seitens Oracle beginnend mit März 2009 regelmäßig für neue CPUs definiert wird. Aktuelle Intel und AMD CPUs haben einen Faktor von 0,5. Das bedeutet, dass man die vorhandenen, echten CPUs mit dem Faktor multipliziert und damit auf die zu lizenzierende Anzahl von Prozessoren kommt.

Ursprünglich sollte dies dazu führen, dass Unterschiede in der Rechenleistung der verschiedenen CPU Hersteller zumindest teilweise ausgeglichen werden. Inzwischen ist das jedoch nicht mehr gegeben, weil die Leistungsfortschritte unterschiedlicher Hersteller sich über die Zeit deutlich geändert haben. Aktuelle Intel oder AMD CPUs bietet im Vergleich zu IBM Power CPUs rund die doppelte Leistung pro Core. Unter Berücksichtigung des Core Faktors muss man für die gleiche Rechenleistung auf einer IBM Power Hardware die 4-fachen Oracle Lizenzkosten in Kauf nehmen. Dies kann man an Hand eines Oracle Single Thread CPU Performance Benchmarks jederzeit selbst verifizieren.

Oracle EE on-Premise Lizenzbedarfsberechnungsbeispiel

Im Fall von Virtualisierungslösungen unter Berücksichtigung der Regelungen in der Oracle Partitioning Policy muss man die ganze Virtualisierungslandschaft auslizenzieren, wenn man kein Hard Partitioning einsetzen kann. In diesem Beispiel sind es zwei Server mit jeweils einer 16 Core AMD CPU – somit in Summe 32 Cores – für die ein Core Faktor von 0,5 anzusetzen ist. Somit muss man in Summe 16 Oracle Enterprise Edition Prozessor Lizenzen besitzen, um die Datenbank mit 8 vCores betreiben zu dürfen.

Würde man bei der gleichen Landschaft Hard Partitioning einsetzen – siehe Hard Partitioning with Oracle Linux KVM – würde man zwar die Möglichkeit für Live-Migration verlieren und müsste beim CPU Pinning gut aufpassen, die richtigen Cores zu pinnen, dafür bräuchten aber nur die 4 physischen Cores unter Berücksichtigung des Core Faktors von 0,5 – somit 2 Oracle Enterprise Edition Prozessor Lizenzen – lizenziert werden.

Aus diesem Beispiel kann man erkennen, dass gerade bei einer Oracle Enterprise Edition Datenbank die richtige Planung und Konfiguration einen großen Unterschied beim Lizenzbedarf ergeben kann.

Referenzen:

CPU Lizenzierung für EE in Authorized Cloud Environments

Ident mit der Oracle Standard Edition gilt das Dokument Licensing Oracle Software in the Cloud Computing Environment, in dem die autorisierten Cloud Services von Microsoft, Amazon und Google aufgeführt sind.

Die Regelung sagt folgendes aus:

  • Wird für die VM eine CPU eingesetzt, die Intel Hyperthreading oder SMT nutzt, so werden 2 vCPUs als ein zu lizenzierender Core gewertet.
  • Wird für die VM eine CPU ohne Intel Hyperthreading bzw. SMT eingesetzt, wird 1 vCPUs als ein zu lizenzierender Core gewertet.
  • Die Oracle Processor Core Factor Table darf NICHT berücksichtigt werden.

Vereinfacht: Für jeden physischen Core wird eine Oracle Enterprise Edition Prozessor Lizenz benötigt. Damit benötigt man für beim Einsatz von Intel oder AMD CPUs immer die doppelte Anzahl an Lizenzen im Vergleich zu on-Premise.

Zusätzlich gilt das Gleiche bezüglich der CPU Performance, wie auch bei der Standard Edition:
Die meisten von den großen Cloud Anbietern genutzten CPUs weisen nur eine Taktrate von 2.2 bis 2.5GHz auf. Eine AMD EPYC™ 9174F hingegen hat eine Mindesttaktrate von 4.1GHz – was (fast) der doppelten Rechenleistung im Vergleich mit den Cloud Anbieter Angebot entspricht!

Dadurch wird man in Cloud Environments immer mehr CPUs benötigen, als bei on-Premise Lösungen.

Referenzen:

Datenbank in der Oracle OCI Cloud

In der Oracle Cloud gibt es noch zusätzliche Unterscheidungen. Folgende Angebote gibt es aktuell:

  • Oracle Base Database Service Standard Edition (BaseDB SE)
  • Oracle Base Database Service Enterprise Edition (BaseDB EE)
  • Oracle Base Database Service Enterprise Edition – High Performance (BaseDB EE-HP)
  • Oracle Base Database Service Enterprise Edition – Extreme Performance (BaseDB EE-EP)
  • Oracle Exadata Database Service on Dedicated Infrastructure bzw. Oracle Exadata Database Service on Cloud@Customer – beides ist (ExaDB)

Diese Angebote unterscheiden sich von den Authorized Cloud Environments durch mehrere Aspekte:

  • Transparent Data Encryption (TDE) for Tablespaces ist in allen Angeboten – auch der Standard Edition – kostenlos enthalten. Da es sich dabei um eine Funktionalität der Advanced Security Option handelt, ist somit eine Verschlüsselung der Daten in einer Standard Edition ausschließlich in der Oracle OCI Cloud verfügbar.
  • Die Angebote High Performance (BaseDB EE-HP) und Extreme Performance (BaseDB EE-EP) inkludieren viele Optionen und Packs (abhängig vom gewählten Angebot). Bei Oracle wird in dem Zusammenhang auch von der Autonomous Database gesprochen, wobei hier nur diese beiden Angebote gemeint sind.
  • Bei Oracle kann man die Anzahl der vCPUs in der Regel viel granulärer konfigurieren als bei den anderen Anbietern. Zusätzlich gibt es für einige Angebote die Möglichkeit, dass man mehr CPU Resourcen nutzt, als man im Vorfeld gebucht hat. Damit kann man kurzfristige Peaks (beispielsweise Monatsabrechnungen) ohne Re-Konfiguration (und Restart) der VM abbilden. Dieses Overbooking wird im nachhinein abgerechnet.

Seit einiger Zeit sind die Oracle OCI Cloud Services auch über Microsoft Azure, Amazon AWS sowie Google Cloud verfügbar – allerdings nicht in allen Regionen der Anbieter. In diesem Fall betreibt Oracle entsprechende Hardware in den jeweiligen Rechenzentren der anderen Cloud Anbieter, die sich ihrerseits um die Vermarktung und Integration in deren Angebote kümmern.

Laut Oracle werden dabei die gleichen Preise verrechnet, die auch in der Oracle OCI Cloud anfallen – allerdings nur für den Datenbankbetrieb. Weitere Leistungen wie Datenverkehr (Traffic) kann zusätzlich anfallen und wird entsprechend verrechnet. Außerdem ist die Latenz beim Zugriff auf die Datenbank möglicherweise etwas höher.

Referenzen:

Zusammenfassung

Die korrekte Lizenzierung von Oracle Datenbanken ist sehr komplex, da viele Aspekte berücksichtig werden müssen. Die folgende Liste dient nur als Anhaltspunkt, es gibt noch weit mehr Aspekte, die den Rahmen dieses Artikels sprengen würden:

  • Datenbank Edition (Standard oder Enterprise)
  • Named User oder Prozessor Lizenzenzierung
  • Welche Datenbank Optionen werden benötigt
  • Welche CPU werden genutzt
  • Virtuelle oder physische Server
  • Bei Virtualisierung, ob die Umsetzung mit Soft- oder Hard-Partitioning (laut Oracle Definition) erfolgt
  • on-Premise oder Authorized Cloud Environment oder Oracle OCI Cloud
  • Spezielle Lizenzierungen wie ASFU, Embedded, etc.
  • Spezielle Lizenzverträge wie ULA, PULA, etc.

Um für ein Unternehmen / ein Projekt die richtige Lizenzierung zu finden, muss man sich entweder sehr intensiv mit dem Thema auseinandersetzen oder sich die Unterstützung von unabhängigen Oracle Lizenzberatern suchen.

Bei DB Masters bieten wir diese Oracle Lizenzberatung in Kombination mit echter Bedarfserhebung, unabhängiger Technologieberatung bis hin zur fachgerechten Umsetzung Ihrer Oracle Datenbank Landschaft an.