Wichtige Oracle Lizenzierungsregeln

Oft zitiert und vielmals missinterpretiert. Die wichtigsten Lizenzierungsregeln für Oracle Lizenzen schaffen weitere Sicherheit in der Nutzung der Oracle Produkte. Oracle gestattet - sofern alles andere korrekt lizenziert wurde - in einigen Bereichen auch den Einsatz der Oracle Software OHNE zusätzliche Lizenzen. Dies unterliegt jedoch klaren Richtlinien, deren Einhaltung letztlich der Kunde im Bedarfsfall nachzuweisen hat.

Für einen Anspruch auf Lizenzierung seitens Oracle ist bereits die Installation der Software auf den Systemen ausreichend, unabhängig davon, ob diese 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 werden mit der Installation der Oracle Database Enterprise Edition defaultmäßig verschiedene Softwarebestandteile, Optionen, Packs installiert, damit deren Nutzung durch einfache Aktivierung erfolgen kann und nicht nochmals Software installiert werden muss. Andere Optionen, wie beispielsweise „Database Vault“ erfordern eine separate Softwareinstallation. Unter Umständen muss dies am Einzelfall geprüft werden.

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 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
• shared Storage erforderlich (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
• kurze Anlaufphase im Disasterfall

Nachteile:

• nur für eine begrenzte Anzahl von Kalendertagen nutzbar
• 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!

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 Oracle Usern 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 support level"?

Entsprechend den Oracle Lizenzbedingungen, die jeder Kunde mit der Annahme des 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), z.B. Oracle Datenbank, ein einheitliches Oracle Supportlevel (matching support level) haben.

"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, Oracle Database Standard Edition 2 und Personal Edition
• Internet Application Server Enterprise Edition, Internet Application Server Standard  Edition, WebLogic Server Enterprise Edition, WebLogic Server Standard Edition, WebLogic Suite und Web Tier

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

Worauf sollte man also achten, dass man nicht unbeabsichtigt in die Verlegenheit eines Lizenzregelverstoßes kommt:

• Prüfen Sie beim Neukauf von Oracle Lizenzen, den Supportstatus Ihrer bereits vorhandenen Oracle Lizenzen.
• Achten Sie beim Kauf von neuer Unternehmenssoftware darauf, mit welchem Supportlevel die dabei oft mit im Bundle angebotenen Oracle Datenbank Lizenzen (ASFU-Lizenzierung) geliefert werden.
• Vergleichen Sie in regelmäßigen Abständen Ihre 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?

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. Oracle Secure Backup ist eine kostenplichtige Software für den Einsatz auf Tape-Backups.

Zum Vorhalten des RMAN Repositorys kann eine separate Oracle Datenbank installiert werden. Oracle erlaubt den Einsatz dieser Datenbank ohne zusätzliche Lizenzierung - auch auf einem eigenen Server. Voraussetzung ist jedoch, dass der Kunde alle Targets des Repositories sauber lizenziert hat. Ein anderweitiger Gebrauch dieser Datenbank ist explizit ohne Lizenzierung nicht gestattet.

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 OEMGC ist eine separate Installation erforderlich.

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