Eine Blogserie in drei Teilen über die Oracle-Datenbank-Lizenzierung

In dieser Blogserie möchten wir mit Ihnen unsere Erfahrungen mit der Lizenzierung von und mit Oracle-Datenbankprodukten teilen. Wir beschreiben die Herausforderungen und deren Lösungsansätze bei der Einführung und Betrieb eines Tools, das (anscheinend) automatisiert einen Lizenzbedarf erstellt.

Gleich zu Beginn der Serie starten wir frontal mit zwei Punkten:

1. Warum werden Tools überhaupt benötigt?

2. Wann kann der Einsatz eines Tools sinnvoll sein?

Teil 1: Verifizierte LMS Tools

Was verstehen wir unter verifizierten LMS Tools?

Der Begriff LMS (License Management Services) ist sicherlich allen bekannt, die schon mal von Oracle auditiert wurden. Aber LMS hat auch eine „helle“ Seite: die LMS „Verified Third-Party Tool Vendors“, eine von Oracle überprüfte, qualifizierte und zertifizierte Anzahl von Toolanbietern, die als Alternative zum LMS Collection Tool (Oracle LMS hauseigenes Messwerkzeug) von Oracle (LMS) zur Erhebung der Oracle-Daten bzw. Erfassung von Oracle-Programmen akzeptiert wird.

Oracle hat jedoch sehr deutlich gemacht, dass die Verwendung eines zertifizierten Tools weder ein Oracle-Audit ersetzt, noch das vertragliche Recht von Oracle, ein Audit durchzuführen, aufhebt.

Die Verifikation verspricht auf den ersten Blick eine genaue Erfassung und Berechnung des komplexen Lizenzbedarfs von Oracle-Datenbankprodukten unter Berücksichtigung vertragsspezifischer Parameter. Wir fragen uns jetzt an dieser Stelle: Stimmt das?

Die Situation

Es gibt einige Hersteller, die Transparenz über die eingesetzte Oracle- Datenbankinfrastruktur anbieten. Von diesen sind die folgenden fünf Hersteller¹ mit unterschiedlichen Produkten verifiziert:

• Aspera (mit SmartCollect)
• Micro Focus (mit Universal Discovery and CMDB)
• iQuate (mit iQSonar)
• Flexera (mit FNMS oder eRunbook)
• Lime Software (mit Lime Software for Oracle License Management).

Diese Verifizierung betrifft jedoch lediglich das Sammeln der Rohdaten, sodass diese unverarbeiteten Daten im Falle eines Audits von Oracle akzeptiert werden:

„It’s important to note that the scope of the verification process only covers the data collection related to the installation and usage of specific Oracle products, namely Oracle Database and associated options. The verification does not include any other Oracle products or the overall capabilities of the vendor’s solution.“

Sinngemäß übersetzt bedeutet das…

„Es ist wichtig zu beachten, dass der Umfang des Verifizierungsprozesses nur die Datensammlung im Zusammenhang mit der Installation und Nutzung bestimmter Oracle-Produkte, nämlich der Oracle-Datenbank und der zugehörigen Optionen, umfasst. Die Verifizierung umfasst keine anderen Oracle-Produkte oder die Gesamtfähigkeiten der Lösung des Herstellers.“

Das Problem

Im Klartext bedeutet der Verifizierungsprozess, dass die Sammlung von Daten zwar verifiziert ist, jedoch nicht die Erkennung von Optionen bzw. Packs oder auch die korrekte Berechnung des Lizenzbedarfs.

Somit kann man davon ausgehen, dass jedes verifizierte Tool in der Qualität der Erkennung und Berechnung unterschiedliche Ergebnisse liefert, da dieser Teil des Produkts nicht verifiziert ist.

Die Lösung

Lassen Sie sich nicht von der „Verifikation“ seitens Oracle blenden. Das Ergebnis eines möglichen Audits durch Oracle LMS kann von dem abweichen, was Ihr Tool als Lizenzbedarf ausgibt.

Daher ist es wichtig, schon bei der Auswahl des Tools darauf zu achten, dass dieses alle eingesetzten Optionen bzw. Packs abbildet, die Ihr Unternehmen einsetzt.

Empfehlenswert an dieser Stelle ist, bei einem PoC (Proof of Concept) die Erkennungslogik der Optionen und Packs anhand Ihrer eigenen Datenbanksysteme zu evaluieren.

Lesen Sie auch…

…den zweiten Teil dieser Blogserie: Virtualisierung mit Hard- und Softpartitioning und

…den dritten Teil dieser Blogserie: Oracle Datenbanklizenzierung mit Tool.

Quelle:

1 https://www.oracle.com/corporate/license-management-services/tooling.html