Oracle Enterprise Manager – Was leistet OEM und was ist bei der Lizenzierung unbedingt zu beachten?

Beim Oracle Enterprise Manager (OEM) handelt es sich um eine Reihe webbasierter Tools zur Verwaltung der Systeme einer Oracle Umgebung, sprich, der Datenbank- und Anwendungsebenen. Mit diesen Tools lassen sich die Oracle Umgebungen überwachen, und sowohl einmalige als auch wiederkehrende Aufgaben der Datenbank- und Anwendungsverwaltung automatisieren. Eine nützliche Technologie. Dennoch erleben viele Unternehmen durch OEM bei Audits Überraschungen hinsichtlich ihrer Compliance. Der Grund: Alles installiert sich von selbst und muss, wenn keine Nutzung erwünscht ist, proaktiv deaktiviert werden. Mit diesem und anderen wichtigen Details im Zusammenhang mit OEM beschäftigt sich dieser Blogbeitrag.

OEM führt einen Großteil seiner Aktivitäten, wie eben Ausführungs- und Überwachungsaufgaben, mit Hilfe intelligenter Agenten, der so genannten Oracle Management Agents, als autonome Prozesse auf einem verwalteten Knoten aus. Die Agenten kommunizieren dabei über das Hypertext Transfer Protocol (HTTP oder HTTPS).

Oracle Enterprise Manager wird mit der Oracle Datenbank installiert. Die Funktionalitäten dürfen vertraglich nur in Verbindung mit der Oracle Database Enterprise Edition verwendet werden, obwohl dies rein technisch auch mit der Oracle Database Standard Edition 2-Programmen funktionieren würde. Die Oracle Enterprise Management Packs sind standardmäßig aktiviert und einsatzbereit.

Oracle Enterprise Manager kann in drei verschiedenen Architekturen bereitgestellt werden:

• Datenbanksteuerung: OEM kommt zur Verwaltung einer einzelnen Oracle Datenbank zur Anwendung. Die Binärdateien werden immer mit der Datenbanksoftware installiert. Das OEM-Repository wird optional als Teil der Datenbankerstellung erstellt und konfiguriert.
• Grid Control: OEM als webbasierte Schnittstelle zur zentralen Verwaltung mehrerer Oracle Umgebungen von einem einzigen Punkt aus. Dies erfordert allerdings eine separate Installation und Konfiguration.
• Cloud-Steuerung: Enterprise Manager Cloud Control ist eine Systemverwaltungs-Software, die zentralisierte Funktionen der Überwachung, Verwaltung und des Lifecycle-Managements für die gesamte IT-Infrastruktur, einschließlich Systemen, auf denen Nicht-Oracle-Technologien ausgeführt werden, bereitstellt. 

Lizenzierung: Hier besteht gegebenenfalls Handlungsbedarf!

Die Lizenz für den Oracle Enterprise Manager ist in der Oracle Database-Lizenz enthalten – eine separate Lizenzierung ist also nicht erforderlich. Die in der Oracle Datenbank enthaltenen OEM-Funktionalitäten sind dazu gedacht, übliche Verwaltungsaufgaben auszuführen, wie zum Beispiel das Erstellen von Datenbankobjekten (Tabellen und Indizes), das Verwalten der Benutzersicherheit, das Sichern und Wiederherstellen der Datenbank sowie das Importieren und Exportieren von Daten.

Standardmäßig aktiviert der Oracle Management Agent (OMA) während des Installationsvorgangs jedoch mehrere sogenannte „Database Enterprise Edition Management Packs“, einschließlich „Diagnostics Pack“, „Tuning Pack“, „Database Lifecycle Management Pack“, „Data Masking & Subsetting Pack“, „Cloud Management Pack for Database“, und zwar ganz unabhängig von dem, was ein Kunde tatsächlich lizenziert hat. 

WICHTIG: Der Endbenutzer muss nicht lizenzierte Pakete daher proaktiv abwählen, nachdem sich die Agenten auf der Zieldatenbank installiert haben, um eine nicht lizenzierte Verwendung zu vermeiden. 

Dadurch wird ein Zeitstempel in der Datenbank gespeichert und "Pack Access Agreed" im zugrunde liegenden Datenbankschema als TRUE gekennzeichnet. Diese in OEM enthaltenen Premium-Funktionalitäten erfordern eine separate Oracle Lizenz, die sogenannten „Oracle Database Enterprise Edition Management Packs“ oder „OEM Pack“. Technisch gesehen existiert ein solches OEM Pack jedoch nicht – diese bestehen aus einer „Suite“ von Datenbank-Funktionen, die Oracle als „lizenzierbar“ einstuft.
In der Vergangenheit, sprich vor der Version Database 10g, wurden OEM-Pakete optional auf Anfrage des Endbenutzers als Teil des OEM-Installationsprozesses installiert. Ab Version 10g werden OEM-Packs immer mit der Konfiguration der grundlegenden OEM-Funktionalität installiert, ohne dass der Endbenutzer Einfluss darauf gehabt hätte. 

Ab dieser Version wurde auch eine neue Funktion für die Endbenutzer eingeführt. Es handelt sich um eine Seite, die als „Management Pack Access“ bezeichnet wird. Darauf können Benutzer den Zugriff auf die OEM Packs-Funktionalität dieser Version aktivieren oder deaktivieren.

Wenn der Zugriff für ein OEM-Paket aktiviert ist, sind alle Elemente der Benutzeroberfläche (Registerkarten, Schaltflächen und Hyperlinks) sowie Funktionen, die dem spezifischen OEM-Paket entsprechen, aktiviert und können von den Endbenutzern aufgerufen werden.

WICHTIG: Das Deaktivieren des Pack-Zugriffs führt zum Deaktivieren oder Ausblenden aller entsprechenden Elemente der Benutzeroberfläche, jedoch nicht zu einer Deinstallation!

Ab Datenbankversion 10g werden OEM-Binärdateien, einschließlich aller Pakete, immer mit der Datenbanksoftware installiert. Die OEM Packs werden standardmäßig mit der Konfiguration des DB Enterprise Manager installiert und aktiviert, der Teil des Datenbank- Erstellungsprozesses ist.

Viele Unternehmen wurden in der Vergangenheit im Zuge eines Audits als nicht konform mit den Oracle Regularien bewertet, weil der „Pack Access“ vereinbart wurde oder Automatic Workload Repository Reports verwendet wurden. Warum dies genau der Fall war, blieb den meisten Verantwortlichen allerdings eher unverständlich – daher hier eine Erläuterung. 

Was bedeutet „Pack Access Agreed“ und wie kommt es dazu?

Ab Oracle Database 10g werden standardmäßig alle OEM Packs installiert und aktiviert. Ziemlich oft nutzen Oracle DB-Administratoren verschiedene Diagnosefunktionen, ohne sich der lizenzrechtlichen Auswirkungen bewusst zu sein. Die OEM Packs können über die GUI-Oberfläche aktiviert und deaktiviert werden. Dennoch wird in dem Moment, in dem eine Aktion von der Schnittstelle aus durchgeführt wird (Aktivieren/Deaktivieren) der Zugriff auf das Paket vereinbart, wobei Informationen über den Zeitstempel sowie den Benutzer, der diese Aktionen durchgeführt hat, gespeichert werden.
OEM Pack Access Enabled bedeutet nicht, dass das Pack auch verwendet wird. Obwohl die Funktionalitäten für die Endbenutzer zugänglich sind, ist es möglich, dass der Benutzer keines der Pakete verwendet hat. Diese Verwendung kann durch die in der Oracle Datenbank gespeicherten Informationen nicht bestätigt werden. Pack-Access Agreed bedeutet, dass der Benutzer eine oder einige der unten aufgeführten Maßnahmen ergriffen hat.
OEM Pack Access Agreed bedeutet: 

• Für 10g Database Control bedeutet dies, dass sich mindestens ein Benutzer bei der OEM-Konsole angemeldet, die Lizenzinformationen auf dem Begrüßungsbildschirm gelesen und auf die Schaltfläche „Ich stimme zu“ geklickt hat, um auf die Datenbankkonsole zuzugreifen
• Für alle anderen Versionen von 10g und höher bedeutet dies, dass mindestens ein Benutzer auf die Seite „Management Pack-Zugriff“ zugegriffen, die Kontrollkästchen für den Paketzugriff geändert hat (standardmäßig alle aktiviert) und auf die Schaltfläche „Anwenden“ geklickt hat.

Infolgedessen bedeutet „Paketzugriff aktiviert und vereinbart“ nicht, dass das entsprechende Paket verwendet wird.

Automatic Workload Repository (AWR) und Automatic Database Diagnostics Monitor (ADDM) 

Die Nutzung der Features AWR (Automatic Workload Repository) oder ADDM (Automatic Database Diagnostic Monitor) – beide Bestandteil des Diagnostics Packs – geschieht im Betrieb häufig. Manchmal erkennen Endbenutzer die Verwendung dieser Funktionen jedoch nicht und werden erst während eines Oracle Audits mit dieser Tatsache konfrontiert. 

Achtung: Es ist nicht ungewöhnlich, dass Support-Mitarbeiter ihren Datenbankadministrator zu irgendeinem Zeitpunkt baten, einen AWS-Bericht zu erstellen, wenn sie ein Ticket beim Oracle Support erneut erstellt haben. Nur war sich wohl niemand bewusst, dass hierfür eine separate Lizenz erforderlich ist.

Neben vielen technischen Benefits, die OEM zu einer praktische Lösung bei der Überwachung und Verwaltung von Datenbank-Umgebungen machen, sollten Oracle Kunden genau prüfen, ob sich hier nicht gegebenenfalls eine Fragestellung in Richtung Compliance ergibt. 

Wie wahrscheinlich ist, dass ein User unwissentlich Packs aktiviert oder einer Nutzung zugestimmt hat, die lizenziert werden muss? Aller Erfahrung nach ist das Risiko groß, sich auf solche Art und Weise - auch wenn dies vollkommen ohne Absicht geschah - bei einem Audit Strafen zuzuziehen. 

Folgende Policy bietet sich an: 

• Man muss entscheiden, welche OEM Packs benutzt werden sollen und die entsprechenden Lizenzen erwerben.
• Für alle OEM-Packs, die nicht lizenziert werden, sollte der Zugriff deaktiviert werden. Das Deaktivieren der Nutzung ist eine einfache Aufgabe, die von einem DBA durchgeführt werden kann und keine Neuinstallation der DB erfordert.

Eine typische Reaktion von Kunden, die erst bei einem Audit davon Kenntnis erhielten, dass sie – wenn auch unabsichtlich – unterlizenziert waren, lautete: „Wer kann das denn wissen, dass sich Sachen von selbst installieren und man sie proaktiv deinstallieren muss?“ Richtig – hier ist nicht nur gründliche Kenntnis aller gültigen Regularien des Herstellers erforderlich, sondern vor allem auch der spezifischen Denkweise und inneren Logik von Oracle.

Wenn man über dieses Know-how im Unternehmen nicht selbst verfügt oder auch nur die stete Bemühung um Aktualisierung Ressourcen bindet, die schlichtweg nicht verfügbar sind, sollte man vielleicht darüber nachdenken, kompetente Beratung ins Boot zu holen; Fachleute, die sich ausschließlich mit Oracle beschäftigen – so wie den Oracle Advisory Service von SoftwareONE.