Wichtige Oracle Lizenzierungsregeln

Oracle Lizenzierung verstehen und richtig einsetzen. Die wichtigsten Lizenzierungsregeln findest du hier im Überblick, klar definiert und ohne Interpretationsspielraum.

Die Erläuterung der wichtigsten Lizenzierungsregeln sollen dir weitere Sicherheit in der Nutzung der Oracle Datenbank Produkte bieten. Einige werden oft zitiert, jedoch vielmals missinterpretiert.

Wir hatten bereits geklärt, dass es für die Lizenzierung von Oracle Produkten unterschiedliche Lizenzarten, Editionen, Metriken etc. gibt, welche es zu berücksichtigen gilt. Oracle gestattet aber auch – sofern alles andere korrekt lizenziert wurde – in einigen Bereichen den Einsatz der Oracle Software ohne zusätzliche Lizenzierung. Dies unterliegt jedoch klaren Richtlinien, deren Einhaltung letztlich der Kunde im Bedarfsfall nachzuweisen hat. Von daher wollen wir hier ein wenig mehr Licht ins Lizenzdunkel bringen.



Grundsätzliches

Für einen Anspruch auf Lizenzierung seitens Oracle ist bereits die Installation und/oder der Betrieb der Software auf den Systemen ausreichend, unabhängig davon, ob die Software / Softwarebestandteile auch tatsächlich genutzt werden. Hier liegt schon der erste wichtige Punkt: „und/oder Betrieb“. Für die Lizenzierungspflicht ist nicht zwingend erforderlich, dass die Oracle Software selbst tatsächlich auf dem System installiert ist – Stichwort Virtualisierung! Es spielt zudem keine Rolle, ob diese Software auf diesen Systemen produktiv genutzt oder nur zu Test- und Entwicklungszwecken eingesetzt wird.

Als Besonderheit bei der Installation der Oracle Database Enterprise Edition werden defaultmäßig verschiedene Softwarebestandteile, wie Datenbank Optionen oder Management Packs gleich mit installiert. Eine (spätere) Nutzung kann dann durch einfache Aktivierung erfolgen. Es muss in der Regel also keine Software nachinstalliert werden. Einige Datenbank Optionen, wie beispielsweise „Database Vault“, erfordern allerdings eine separate Softwareinstallation. Im Bedarfsfall sollte das einzeln geprüft werden.

Lizenz-Tipp: Um sicher zu gehen, dass nicht aus Versehen irgendwelche lizenzierungspflichtigen Softwarebestandteile (Datenbank Optionen oder Management Packs) aktiviert und möglicherweise auch unbewusst genutzt werden, sollten bei oder nach der Erstinstallation grundsätzlich einmal alle Management Packs und Optionen aktiviert und dann gleich wieder deaktiviert werden. Das ist dann so in der History auch ersichtlich und vermeidet im Falle eines Oracle Lizenzaudits in Erklärungsnöte zu kommen.

10-Tage-Regel

Geht es darum eine Ausfallsicherheit für einen Oracle Node aufzubauen und dabei die richtige Oracle Lizenzierung zu finden, wird sehr oft die sogenannte 10-Tage-Regel zitiert. Leider gibt es hier immer wieder falsche Informationen und Missinterpretationen. Deshalb wollen wir das an dieser Stelle einmal mit dem entsprechenden Auszug aus dem Software Investment Guide klarstellen (freie Übersetzung, den Originaltext in Englisch stellen wir Ihnen gern auf Anforderung zur Verfügung):

Kurz zusammengefasst kann die 10-Tage-Regel eingesetzt werden:

„Diese Failover-Datenwiederherstellungsmethode ist ein Beispiel für eine Cluster-Bereitstellung mit mehreren Knoten/Servern die Zugriff auf einen einzigen Speicher/SAN haben. In solchen Fällen gestattet Oracle Ihre Lizenz für die aufgeführten Programme auf der US Oracle Technology Price List (http://www.oracle.com/corporate/pricing/pricelists.html) die in Anspruchnahme der 10-Tage-Regelung. Diese beinhaltet das Recht, das/die lizenzierte(n) Programm(e) auf einem nicht zu lizenzierendem Ersatzcomputer in einer Failover-Umgebung für insgesamt bis zu zehn separate 24-Stunden-Zeiträume pro Kalenderjahr auszuführen.

Beispiel: wenn ein Failover-Knoten am Donnerstag zwei Stunden und am Freitag drei Stunden lang ausgefallen, zählt dies als zwei 24-Stunden-Zeiträume.

Das vorstehende Recht gilt nur, wenn eine Anzahl physischer bzw.logische Maschinen, wie in der Partitionierungsrichtlinie von Oracle definiert (ausführlich in https://www.oracle.com/assets/partitioning-070609.pdf) in einem Cluster angeordnet sind und eine gemeinsame Festplattenarray besitzen, das sich in einem einzelnen Rechenzentrum befindet. Wenn der Primärknoten ausfällt, fungiert der Failover-Knoten als Primärknoten. Sobald der primäre Knoten repariert ist, müssen Sie entweder auf den alten Primärknoten zurück wechseln oder den repariert Primärknoten dann explizit als Failoverknoten ausweisen. Sobald der Failover-Zeitraum zehn 24-Stunden-Zeiträume überschreitet, gilt der Failover-Knoten als aktiviert und muss lizenziert werden. Darüber hinaus ist nur ein Failover-Knoten pro Clusterumgebung kostenlos, selbst wenn mehrere Knoten als Failover konfiguriert sind.

Auf die zehn 24-Stunden-Zeiträume werden Ausfallzeiten zu Wartungszwecken angerechnet. … „

… ansonsten gelten die selben Lizenzierungsrichtlinien, wie bei der ganz normalen Lizenzeriung der Clusterknoten.

  • bei einer anerkannten Failover/ Fail Safe Konstellation
  • für bis zu 10 separate 24-Stunden-Perioden pro Kalenderjahr
  • für bis zu 1 Failover/ Fail Safe Knoten je Infrastruktur
  • mit einem shared Storage / Disk Array (ungespiegelt*) in einem einzelnen Rechenzentrum
  • es muss zwingend wieder auf den Primärknoten zurückgeschwenkt werden, sobald dieser wieder verfügbar ist oder der „alte“ Primärknoten muss explizit als als Failoverknoten ausgewiesen werden.

Vorteile:

  • Ersparnis der Lizenzkosten für 1 Failover/ Fail Safe Knoten
  • kostengünstige HA Lösung zur Absicherung von Knotenausfall
  • im Schwenkfall kein Datenverlust, da identische Datenbasis durch das gemeinsam genutzte Storage
  • kurze Anlaufphase im Disasterfall

Nachteile:

  • nur für eine begrenzte Anzahl von Kalendertagen nutzbar, den Nachweis dazu muss der Kunde führen und im Bedarfsfall bei LMS/GLAS vorlegen können
  • ggf. zusätzliche Kosten für Storage wenn ursprünglich mit internen Platten gerechnet wurde
  • keine Absicherung bei Storageproblemen
  • keine Absicherung bei logischen Datenbankfehlern
  • keine Absicherung bei Ausfall eines RZ

*) Ganz wichtig: die 10-Tage-Regel gilt NICHT, wenn das Storage gespiegelt ist! In diesem Fall handelt es sich um Remote Mirroring!

Matching Support Level / Matching Service Level

Nicht selten trifft man bei Oracle Lizenzchecks auf die Tatsache, dass in einem Unternehmen Oracle Lizenzen sowohl mit als auch ohne gültigem Supportvertrag vorhanden sind. Für den ersten Moment scheint dies irrelevant, jedoch ist den wenigsten Lizenznehmern klar, dass damit ein Verstoß gegen die Oracle Lizenz- und Supportrichtlinien einhergeht. Im Falle eines Lizenzaudits durch Oracle License Management Services (LMS) kann man so schnell in eine unangenehme Situation geraten.

Was steckt also genau hinter dem Passus „matching service level“?

Entsprechend den Oracle Lizenzbedingungen, die jeder Kunde mit der Annahme des (Transactional) Oracle Master Agreement (kurz: OMA oder T-OMA, früher auch bekannt als Oracle License- and Service Agreement, OLSA) und den dazugehörigen Oracle Software Technical Support Policies anerkennt, müssen alle Lizenzen einer Produktfamilie (license set) ein einheitliches Oracle Support Service Level (matching support level) haben. Eine Produktfamilie umfasst beispielsweise alle Oracle Datenbank Produkte, eine andere alle Oracle Application Server Produkte.

Dazu heißt es bei Oracle:

When acquiring technical support, all licenses in any given license set must be supported under the same technical support service level (e.g., Software Update License & Support or unsupported).“

… wobei ein license set definiert ist als

programs that share the same source code

wie beispielsweise:

Konkret heißt das also: entweder ALLE Oracle Datenbank Lizenzen sind mit Support oder ALLE Oracle Datenbank Lizenzen sind ohne Support. Wenn du Lizenzen verschiedener Produktfamilien, z.B. Oracle Datenbank Lizenzen und Oracle WebLogic Server Lizenzen hast, muss das Supportlevel zwar innerhalb der Produktfamilie einheitlich sein, zwischen den Produktfamilien darf das Supportlevel jedoch differieren. In diesem Fall könntest du beispielsweise deine Datenbank Lizenzen mit Support betreiben und die WebLogic Server Lizenzen ohne Support.

Worauf solltest du also achten, wenn du nicht unbeabsichtigt in die Verlegenheit eines Lizenzregelverstoßes kommst?

  • Prüfe beim Neukauf von Oracle Lizenzen den Supportstatus deiner bereits vorhandenen Oracle Lizenzen.
  • Achte beim Kauf von neuer Unternehmenssoftware darauf, mit welchem Supportlevel die dabei meist im Bundle angebotenen Oracle Datenbank Lizenzen (ASFU-Lizenzierung) geliefert werden.
  • Vergleiche in regelmäßigen Abständen deine vorhandenen Oracle Lizenzen mit den jährlich zu verlängernden Supportverträgen. Sind alle Supportverträge verlängert worden oder wurden einzelne Supportverlängerungen nicht mehr beauftragt?

Ist dir das alles zu nervig, zu aufwendig oder zu kompliziert, suche dir einen kompetenten Oracle Partner, der dir das alles abnimmt.

RMAN Repository und Oracle Secure Backup

Der Oracle Recovery Manager (RMAN) wird von Oracle mit jeder Datenbank Edition mitgeliefert. Er kann für die Einrichtung und Verwaltung von Backups ohne Zusatzkosten vom Kunden genutzt werden. Im Gegensatz dazu ist Oracle Secure Backup ist eine kostenpflichtige Software für den Einsatz auf Tape-Backups.

Zum Vorhalten des RMAN Repository darfst du eine separate Single Oracle Datenbank installieren. Oracle erlaubt den Einsatz dieser Datenbank ohne zusätzliche Lizenzierung – auch auf einem eigenen Hardware Server. Voraussetzung ist jedoch, dass der Lizenznehmer alle Targets des Repository sauber lizenziert hat. Ein anderweitiger Gebrauch dieser Datenbank ist explizit ohne Lizenzierung nicht gestattet.

Wichtig: Es wird nochmal ausdrücklich darauf hingewiesen, dass die Repository Datenbank auf eigener Hardware laufen darf/kann/soll. Eine Installation auf einer virtuellen Maschine mag zwar technisch und administrativ reizvoll sein, führt dann jedoch sofort zur Lizenzierungspflicht! Gleiches gilt für das Clustern der Repository Datenbank. Es gelten dann die selben Lizenzierungsregeln wie für die ganz normale Datenbank – Stichwort Softpartitioning.

Oracle Enterprise Manager (OEM) Grid Control / Cloud Control

Der Oracle Enterprise Manager Grid Control / Cloud Control ist ein Administrationswerkzeug zur zentralen Verwaltung, Überwachung und Administration von Oracle Datenbanken (u.a.). Für das Aufsetzen des OEMCC ist eine separate Installation erforderlich.

Für den Betrieb des OEMCC kann eine separate Single Oracle Datenbank zum Vorhalten des Repository installiert werden. Oracle erlaubt den Einsatz dieser Datenbank ohne zusätzliche Lizenzierung – auch auf einem eigenen Hardware Server, jedoch ausschließlich zum Betrieb des OEMCC. Voraussetzung hierfür ist, dass der Kunde alle Targets des Repository sauber lizenziert hat. Ein anderweitiger Gebrauch dieser Datenbank ohne Lizenzierung ist nicht gestattet.

Wichtig: Es wird nochmal ausdrücklich erwähnt, dass die Repository Datenbank auf einer eigenen Hardware laufen darf/kann/soll. Eine Installation auf einer virtuellen Maschine mag zwar sowohl technisch als auch administrativ reizvoll sein, führt dann jedoch sofort zur Lizenzierungspflicht! Das gleiche gilt für das Clustern der Repository Datenbank. Dann gelten die selben Lizenzierungsregeln wie für die ganz normale Datenbank – Stichwort Softpartitioning.

Praxis-Tipp: Das RMAN Repository und das OEMCC Repository können auf dem selben Server laufen. Virtuelle Umgebungen sind jedoch lizenzpflichtig!

Oracle in virtuellen Umgebungen unter Nutzung von VMware, Microsoft Hyper-V oder KVM

Bei der Installation und/oder Nutzung von Oracle Software in speziell segmentierten Bereichen, unterscheidet Oracle in die Hauptkategorien Hardpartitioning, Softpartitioning und „Oracle trusted partitioning“.

Je nachdem, welche Partitionierungsmethode definiert ist, erlaubt Oracle in Ausnahmefällen eine Limitierung der Prozessorlizenzierung auf die Anzahl der tatsächlich genutzten Prozessoren. Welche Voraussetzungen jeweils zu erfüllen sind, um tatsächlich in den Genuss einer Limitierung zu gelangen, ist recht komplex. Sie sollte am konkreten Einzelfall behandelt werden. Der kompetente Oracle Partner deines Vertrauens wird dir hier sicherlich professionelle Unterstützung bieten. Nur eines vorab: VMware, Microsoft Hyper-V und Oracle VM Umgebungen werden als Softpartitioning definiert. Das bedeutet, dass alle physischen Server der virtuellen Umgebung durchlizenziert werden müssen.

In diesem Zusammenhang hast du möglicherweise auch schon vom sogenannten „VLAN Approval“ gehört. Die Lizenzspezialisten von ASPICON helfen dir auch hier gern weiter.

Weitere Informationen zur Definition des Partitionings erhältst du auf der Oracle Website.

Startseite » Wichtige Oracle Lizenzierungsregeln