Wichtige Oracle Lizenzierungsregeln

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

Oft zitiert und vielmals miss-interpretiert. Die Erläuterung der wichtigsten Lizenzierungsregeln sollen weitere Sicherheit in der Nutzung der Oracle Datenbank Produkte schaffen.

Oracle gestattet sogar – sofern alles andere korrekt lizenziert wurde – in einigen Bereichen auch 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.

Für einen Anspruch auf Lizenzierung seitens Oracle, ist bereits die Installation der Software auf den Systemen ausreichend, unabhängig davon, ob die Software / Softwarebestandteile auch tatsächlich genutzt werden. Es spielt zudem keine Rolle, ob diese Software auf produktiven Systemen genutzt oder nur zu Test- und Entwicklungszwecken eingesetzt wird.

Als Besonderheit bei der Installation der Oracle Database Enterprise Edition werden defaultmäßig verschiedene Softwarebestandteile, Optionen, Packs installiert, damit deren (spätere) Nutzung durch einfache Aktivierung erfolgen kann und nicht nochmals Software installiert werden muss. Einige Datenbank Optionen, wie beispielsweise „Database Vault“ erfordern allerdings eine separate Softwareinstallation. Im Bedarfsfall sollte dies einzeln geprüft werden.

Lizenz-Tipp: Um sicher zu gehen, dass nicht aus Versehen irgendwelche lizenzierungspflichtigen Softwarebestandteile, Datenbank Optionen oder Management Packs aktiviert und ggf. auch unbewusst genutzt werden, sollten bei oder nach der Erstinstallation grundsätzlich einmal alle 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

Sehr oft wird von Kunden die sogenannte 10-Tage-Regel zitiert, wenn es darum geht die richtige Oracle Lizenzierung zu finden. Leider gibt es hier immer wieder falsche Informationen und Missinterpretationen. Deshalb wollen wir dies hier 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):

Lösungen wie Oracle FailSafe (inkludiert mit Oracle EE, SE2, SE oder SE1) oder Drittanbieterlösungen wie Veritas, HP Service Guard, HACMP, Linux HA – Heartbeat werden häufig zum Management von Failover Lösungen eingesetzt. Innerhalb dieser Umgebungen, erlaubt Oracle korrekt lizenzierten Kunden einige Softwaretechnologien für bis zu 10 Kalendertage pro Kalenderjahr auf einem unlizenzierten Rechner zu betreiben. Ist der Primary Node wieder hergestellt/einsatzbereit, muss zwingend auf den Primary zurückgestellt werden. Dauert die Failover Periode länger als 10 Tage, muss der Failover-Rechner ebenfalls vollständig lizenziert werden. Weiterhin gilt, dass diese Regelung pro Infrastruktur für nur 1 Failover Node angewendet werden darf, auch wenn mehrere Failover Nodes konfiguriert sind. Unerheblich dabei ist, ob es sich dabei um eine geplante oder ungeplante Downtime des Primary handelt. Jede andere Verwendung erfordert eine vollständige Oracle Lizenzierung des Failover Nodes. In der Failover-Umgebung muss für alle Knoten zwingend die gleiche Lizenzmetrik angewandt werden. Zusätzlich müssen auch alle auf dem Primary eingesetzten Optionen lizenziert werden. Diese wiederum müssen in Anzahl und Metrik mit den Lizenzen der jeweils assoziierten Datenbank übereinstimmen„.

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

  • bei einer anerkannten Failover/Failsafe Konstellation
  • für bis zu 10 Kalendertage pro Jahr
  • für bis zu 1 Failover/Failsafe Knoten je Infrastruktur
  • mit einem shared Storage / Disk Array (ungespiegelt*)
  • es muss zwingend wieder auf den Primärknoten zurückgeschwenkt werden, sobald dieser wieder verfügbar ist

Vorteile:

  • Ersparnis der Lizenzkosten für 1 Failover/Failsafe 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, Nachweis muss Kunde führen
  • ggf. zusätzliche Kosten für Storage
  • keine Absicherung bei Storageproblemen
  • keine Absicherung bei logischen Datenbankfehlern

*) 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 Lizenzberatungen 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 Supportlevel (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:

  • Database Enterprise Edition, Database Standard Edition, Database Standard Edition One, and Personal Edition.
  • Internet Application Server Enterprise Edition, Internet Application Server Standard Edition, WebLogic Server Enterprise Edition, WebLogic Server Standard Edition, WebLogic Suite, and Web Tier.

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 Oracle Datenbank Lizenzen mit Support betreiben und die Oracle 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 oft mit 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 und 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 kann eine separate Single Oracle Datenbank installiert werden. 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 soll nochmal ausdrücklich erwähnt werden, 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! Das gleiche 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.

Zum 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 soll nochmal ausdrücklich erwähnt werden, 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! Das gleiche gilt für das Clustern der Repository Datenbank. Es gelten dann 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, Hyper-V oder KVM

Bei der Installation und/oder Nutzung von Oracle Software in speziell segmentierten Bereichen, unterscheidet Oracle in zwei Hauptkategorien sogenanntes Hardpartitioning oder Softpartitioning. Seit neustem existiert noch ein „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 und sollte am konkreten Einzelfall behandelt werden. Der kompetente Oracle Partner deines Vertrauens wird dir hier sicherlich professionelle Unterstützung bieten. Nur eines vorab: VMware und Hyper-V Umgebungen werden als Softpartitioning definiert, was bedeutet dass alle 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.