Der Lizenzierungspflicht für Oracle-Produkte unterstehen grundsätzlich alle Server, auf denen Oracle-Programme installiert sind beziehungsweise auf denen sie laufen. Um dieser Lizenzierungspflicht gerecht zu werden, können Unternehmen zwischen zwei unterschiedlichen Lizenzmetriken wählen: "Prozessor" oder "Named User Plus" (NUP). Diese beiden grundlegenden Metriken liefern letztendlich die Kriterien für die Bewertung und Berechnung des Lizenzierungsbedarfs eines Unternehmens.
Inhaltlich unterscheiden sich die zwei Metriken indes. Es gibt verschiedene Regeln, Definitionen und Business Practices. Maßgeblich für den Kunden ist jedoch immer das "Oracle License and Service Agreement" (OLSA), das beim Kauf gültig war. Dazu können je nach Einzelfall auch Sondervereinbarungen gelten.
Lizenzmetriken
Bei der Named-User-Plus-Metrik (NUP-Metrik) werden alle berechtigten Personen sowie alle nicht benutzerbedienten Geräte lizenziert, die auf die Oracle-Programme zugreifen. Die Zählung der zu lizenzierenden Personen/Geräte erfolgt am sogenannten Multiplexing-Frontend. Bei dieser Metrik wertet Oracle neben den typischen "Multiplexern" wie Applikations-Servern oder Transaktionsmonitoren auch Datentransfers als Multiplexer, wenn diese Datentransfers nicht den Kriterien des File-Transfers (manuell durchgeführt) und des "Automatic Batching" (zeitlich automatisiert, Daten müssen kopiert werden, Transfer muss zwischen zwei verbundenen relationalen Datenbanken stattfinden) entsprechen.
Folglich sind zum Beispiel die Benutzer eines externen Systems als NUP zu lizenzieren, wenn dieses Daten über ein XML-File liefert, das per FTP übermittelt und dann automatisch eingelesen wird. Lässt sich die Anzahl der zu lizenzierenden Personen und Geräte nicht feststellen - wie in dem geschilderten Fall oder bei einer frei zugänglichen Internet-Applikation -, so muss nach der Prozessormetrik lizenziert werden. Bei einer Lizenzierung nach NUP gibt es für diverse Produkte Minimum-Bedingungen, so dass sich die Zahl an Servern und CPUs wiederum auf die Zahl der zu lizenzierenden NUP auswirken kann.
Bei der Prozessor-Metrik sind alle CPUs der Server zu lizenzieren, auf denen Oracle-Software läuft beziehungsweise installiert ist. Die Benutzerzahl spielt dabei keine Rolle. Was auf den ersten Blick als eindeutiger Maßstab erscheint, offenbart im Detail allerdings gravierende Unterschiede. Für die Produkte mit "Standard Edition" oder "Standard Edition One" im Namen (mit Ausnahme der so benannten Java-Editionen) gilt aus Oracle-Sicht der gefüllte Prozessorsockel als zu lizenzierende CPU, unabhängig von der Anzahl der Cores, die sich auf dem Prozessorsockel befinden. Für die übrigen Produkte ist die Summe der Cores pro Prozessortyp zu bilden, die dann mit dem entsprechenden Prozessorfaktor multipliziert wird. Minimum- und Maximum-Bedingungen erschweren es den Anwendern an dieser Stelle, die Compliance-Regeln einzuhalten.
Die richtige Edition
Neben den benötigten Funktionen bestimmt auch die Größe des Servers, genauer gesagt seine maximale Ausbaufähigkeit, die entsprechende Edition der Oracle-Datenbank, die der Kunde am besten unter Lizenz nimmt. Dank moderner Prozessorarchitekturen mit beispielsweise zwölf Cores pro Sockel und vier Prozessorsockeln lassen sich mit der Oracle Database Standard Edition (SE) bereits leistungsstarke DatenbankServer realisieren. Da bei der Standard Edition ein gefüllter Sockel als Prozessor gezählt, bei der Enterprise Edition (EE) hingegen die Summe der im Server befindlichen Cores mit dem jeweiligen CPU-Faktor multipliziert wird, ergeben sich bei der Berechnung der Lizenzkosten erhebliche Unterschiede.
Zwei Rechenbeispiele im Vergleich - vorausgesetzt wird als Server ein VierSockel-Gerät mit vier belegten Sockeln mit AMD-6174-Prozessor:
-
DB SE: 4 Sockel x 13.813 EUR = 55.252 EUR
-
DB-EE: 4 Sockel x 12 Cores x 0,5 (Prozessorfaktor für AMD 6174) x 37.492 EUR = 899.808 EUR
Allerdings müssen Anwender bei der Wahl der Edition auch funktionale Unterschiede einkalkulieren. So sind für die Database Standard Edition weder Optionen wie Partitioning oder Advanced Compression Option noch Management Packs wie Diagnostics Pack oder Tuning Pack verfügbar. Mit den kostengünstigen Editionen lässt sich heute jedoch eine Leistung erzielen, die bis vor einigen Jahren nur mit einer Enterprise Edition möglich gewesen wäre. Zusätzlich zu diesen Maßnahmen empfiehlt es sich aber generell, den genauen Anwendungsfall der Applikation in Verbindung mit der geplanten Oracle-Architektur zu untersuchen und zu prüfen, ob der Einsatz von Zusatzoptionen nötig ist. Mit einem zielgerichteten Lizenz- und Architektur-Management lassen sich die Kosten für eine Oracle-Architektur in vielen Unternehmen noch erheblich senken.
Lizenzmodelle
Je nach Einsatz und Integration in Software beziehungsweise Geräte bietet Oracle grundsätzlich drei Lizenzformen an:
Full Use: Bei dieser Lizenzform kauft der Kunde die Lizenzen bei Oracle oder einem Oracle-Partner. Er darf mit diesen Lizenzen beliebig viele Applikationen betreiben, solange er die geltenden Lizenzregeln berücksichtigt. Der Anwender geht ein direktes Vertragsverhältnis mit Oracle ein und kann den Support des Softwareherstellers in Anspruch nehmen - sofern er einen Supportvertrag abgeschlossen hat.
Application Specific Full Use (ASFU): Diese Lizenzform erwirbt der Kunde beim Kauf einer Standardsoftware über einen mit Oracle verbundenen Lösungspartner (Independent Software Vendor = ISV). Der Käufer darf nach diesem Modell die Lizenzen nur im Rahmen der Standardapplikationen nutzen, mit denen er sie erworben hat. Die Datenbank darf er weder selbst erweitern noch eigenentwickelte Applikationen zusätzlich betreiben.
Embedded Software Licence (ESL): Hier kauft der Kunde ein komplettes Anwendungssystem, in dem Oracle-Produkte als "Black Box" enthalten sind. Bei dieser Lizenzform ist dem Anwender unter Umständen gar nicht bekannt, dass das erworbene System Bestandteile von Oracle enthält.
Virtualisierung
Viel diskutiert werden zurzeit die Regeln, die Oracle für die Lizenzierung in partitionierten und virtualisierten Umgebungen festgelegt hat. Maßgeblich für die Lizenzierung in diesen Umgebungen ist das Partitioning-Dokument von Oracle (http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf). Der Hersteller unterscheidet für die Lizenzierung zwischen zwei Partitionierungsarten:
Soft-Partitioning: Alle Prozessoren/Cores des gesamten Servers beziehungsweise Clusters müssen lizenziert werden (zum Beispiel VMware, HyperV).
Hard-Partitioning: Nur die zugewiesenen Prozessoren müssen lizenziert werden (Oracles Virtualisierungslösungen wie LPAR und Solaris 10 Capped Container).
Das bedeutet, dass zum Beispiel bei der Verwendung von Produkten des Server-Virtualisierungs-Marktführers VMware alle Server eines ESX-Clusters zu lizenzieren sind, sobald ein Oracle-Produkt auf diesem Cluster installiert ist beziehungsweise läuft.
Fazit:
Die Regeln der Lizenzmetriken "Named User Plus" und "Prozessor" sind gut zehn Jahre alt. Die stetige Innovation in der IT zwang Oracle, die Metriken anzupassen. Auch die Architekturen bei den Kunden verändern sich laufend. Wenn es darum geht, die Compliance sicherzustellen und Einsparpotenziale zu heben, kristallisieren sich in der Praxis erfahrungsgemäß drei Kernfragen heraus:
-
Entspricht die Lizenzierung nach der Named-User-Plus-Metrik der aktuellen Situation bezüglich der Anbindung technischer Geräte und Datenschnittstellen?
-
Reicht die Lizenzierung auch hinsichtlich der Verwendung von Virtualisierungstechniken aus?
-
Welche Datenbank-Edition befindet sich im Einsatz, und handelt es sich dabei um die richtige Wahl im Hinblick auf die Lizenzierungserfordernisse? (ba)