Nachdem der erste Teil dieser Artikelserie [1] einen Überblick über die Funktionen und Einsatzmöglichkeiten des Oracle Enterprise Managers Grid Control (EM) gegeben hat, widmet sich dieser Artikel der Installation und der grundlegenden Konfiguration des EM. Dazu werden zunächst die verschiedenen Installationsmöglichkeiten vorgestellt und dann beispielhaft eine der Varianten ausführlicher beschrieben. Abschließend erfolgt ein Überblick über die grundlegenden Konfigurationseinstellungen.

Komponenten

Um Grid Control in der aktuellen Version 10.2.0.3 aufzusetzen, sind meist mehrere Schritte erforderlich, da Oracle im Internet lediglich für Linux x86-64 und HP-UX Itanium ein Installationspaket in diesem Patchlevel anbietet. Für alle anderen Plattformen muss zunächst die ältere Version 10.2.0.1 oder 10.2.0.2 installiert und anschließend per Patch auf den aktuellen Stand gebracht werden.

Für Solaris z. B. umfasst der Download des Installers etwa 2,4 GB, der Patch ist nochmal etwa halb so groß.

Generell beinhalten die Downloads sämtliche für eine vollständige Installation erforderlichen Komponenten. Neben dem Oracle Management Server (OMS) ist somit auch ein DBMS und ein Agent enthalten. Die Möglichkeit eines separaten Downloads der Application Server Komponente des OMS besteht nicht.

Beim Start des Installers wird der Anwender vor die Wahl gestellt, ob er den EM zusammen mit einer neuen Datenbank für das Repository installieren möchte oder ob eine bestehende Datenbank das Repository aufnehmen soll. Für den vollen Funktionsumfang des EM ist dabei eine Oracle Datenbank der Enterprise Edition erforderlich. Die Datenbank erfordert keine gesonderte Lizenz, solange sie ausschließlich für das Repository des EM genutzt wird und alle zu überwachenden Zielsysteme korrekt lizensiert sind. Eine identische Aussage gilt im Übrigen für die Catalog-DB des RMAN.

Installation der Datenbank

Im Folgenden wird der Ablauf der Installation beispielhaft an einem Solaris-System gezeigt. In unseren Projekten installieren wir immer zunächst separat eine Datenbank im höchsten Patchlevel. Dieses Vorgehen reduziert die Komplexität des Installationsverfahrens und stellt gleichzeitig den aktuellen Level der Datenbank sicher. Auch in unserem Beispiel installieren wir die Datenbank für das Repository separat und setzen anschließend den OMS auf.

Der Download des DBMS in der Version 10.2.0.1 erfolgt als cpio-Archiv, das zunächst im Dateisystem extrahiert werden muss. Das Skript runInstaller startet anschließend den Installationsvorgang, durch den der Administrator in einer grafischen Oberfläche in wenigen Schritten geführt wird. Dabei muss im Wesentlichen festgelegt werden, unter welchem Pfad die Installation erfolgen soll.

Wir empfehlen, zunächst auf die Erstellung einer Datenbank zu verzichten und diese im Anschluss über den DBCA zu erstellen. Ist das DBMS erfolgreich installiert, kann es per Patch auf die aktuelle Version gebracht werden.

Anders als das DBMS selbst, wird der Patch von Oracle als zip-Archiv bereitgestellt. Nach dem Entpacken startet man wiederum das Skript runInstaller im Verzeichnis "Disk1". Auch hier führt ein Installationsdialog in wenigen, leicht verständlichen Schritten durch den gesamten Vorgang.

Abb. 1: Installation des OMS. (vergrößern)

Abb. 2: Connect zur EMREP. (vergrößern)

Abb. 3: Setup. (vergrößern)

Abb. 4: Voreinstellungen. (vergrößern)

Installation des OMS

Nach der Installation der Datenbank kann das Schema für das Repository erstellt werden. Die Instanz bekommt, dem Beispiel des Grid Control Installers folgend, den Namen "emrep" (für EM Repository).

Falls das vom EM benötigte Package DBMS_ SHARED_POOL noch nicht installiert ist, muss die Installation nun durch Aufruf der Skripte dbmspool.sql und prvtpool.plb im Verzeichnis $ORACLE_HOME/rdbms/admin nachgeholt werden. Zusätzlich sollten die Werte der Parameter session_cached_cursors (>=200) und aq_tm_processes (>=1) in der init.ora überprüft und gegebenenfalls entsprechend den Anforderungen angepasst werden.

Nun kann mit der eigentlichen Installation des EM begonnen werden. Die benötigten Dateien für die Version 10.2.0.1 werden von Oracle in Form mehrerer zip-Files bereitgestellt, die extrahiert werden müssen. Wie bei dem DBMS wird die Installation durch einen Aufruf von runInstaller gestartet. Zunächst ist die Installationsmethode zu wählen. Zur Wahl stehen die Installation unter Verwendung einer neuen oder einer bestehenden Datenbank sowie die Möglichkeiten, einen neuen, zusätzlichen Management Service inklusive Agent oder auch nur einen Agenten zu installieren.

In unserem Fall ist hier die Option zur Installation unter Verwendung einer bestehenden Datenbank zu wählen (siehe Abbildung 1). Anschließend werden der Name des Datenbank-Hosts, der verwendete Port, die SID der Zielinstanz und das Passwort des SYS-Users abgefragt. Darüber hinaus besteht die Möglichkeit, die Speicherorte der zwei neu anzulegenden Tablespaces festzulegen (siehe Abbildung 2).

Grid Control legt dort einen Management Tablespace an, der mindestens 20 MB groß sein muss, und einen mindestens 100 MB großen Tablespace für die eigentlichen Daten. Bevor nun die eigentliche Installation startet, werden noch einmal die Systemvoraussetzungen überprüft. Dabei wird unter anderem auch getestet, ob in der Repository-Datenbank der User/das Schema SYSMAN existiert. Ist dies der Fall, muss der Anwender einer Löschung dieses Schemas zustimmen, da für den EM ein neuer User dieses Namens angelegt werden muss.

Neben dem OMS wird automatisch ein Agent installiert, der das System überwacht, auf dem der OMS läuft. Dieser Agent wird bereits bei der Installation mit dem OMS verbunden, so dass die Informationen über diesen Rechner sofort im EM abrufbar sind. Befindet sich die Repository-Datenbank auf einem anderen Rechner als der OMS, so sollte nicht vergessen werden, auch dort einen Agenten zu installieren. Für den Fall, dass während der Installation Probleme auftreten, werden für jede der Komponenten OMS, DBMS und Agent im Verzeichnis cfgtoollogs/cfgfw unterhalb des jeweiligen Home-Verzeichnisses ($OMS_HOME, $AGENT_HOME und $DB_HOME) umfangreiche Logfiles erstellt.

Anschließend wird der Patch für den OMS eingespielt. Die notwendigen Dateien werden aus dem Technet heruntergeladen und der Vorgang über runInstaller gestartet. Nach dem Start werden die Verbindung zur EMREP und das SYSMAN Passwort erfragt.

Erste Konfigurationsschritte

Nachdem die Installation abgeschlossen ist, kann nun eine grundlegende Konfiguration des EM vorgenommen werden. Der Zugriff auf das System erfolgt per Webbrowser auf die Adresse http://<EM_HOST>:4889/em. Die Anmeldung muss zunächst als Super-Administrator SYSMAN mit dem während der Installation festgelegten Passwort erfolgen.

Die grundlegenden Konfigurationsmöglichkeiten des EM finden sich unter den Menüpunkten Setup (siehe Abbildung 3) und Voreinstellungen (siehe Abbildung 4). Unter Voreinstellungen können Usernamen und Passworte für die zu überwachenden Systeme hinterlegt, Benachrichtigungspläne erstellt und das Menü des EM beeinflusst werden. Unter dem Punkt Setup verbergen sich noch grundlegendere Konfigurationen, wie die Benutzer- und die Zugriffsverwaltung für die verschiedenen Management Packs und die Hinterlegung von Zugangsdaten für den Mail-Versand.

Setup

Management Packs

Oracle empfiehlt, nach der ersten Anmeldung zunächst unter Setup, "Zugriff auf Management Packs" festzulegen, welche Management Packs in Kombination mit welchem zu überwachenden Ziel genutzt werden können.

Da einige Packs lizenzpflichtig sind, sollte diese Einstellung sehr gründlich vorgenommen werden. Ein mit "Oracle Enterprise Manager 10g Lizenzinformationen" betitelter Link führt zu einer knappen Übersicht/Beschreibung der verschiedenen Packs. Da daraus aber nicht sofort ersichtlich ist, welche Funktion bzw. welcher Link zu welchem Pack gehört, hat Oracle eine recht nützliche Hilfe eingebaut, die durch einen Klick auf ein kleines Symbol in Form eines Blattes Papier am unteren Rand jeder Seite des EM ein- bzw. ausgeschaltet werden kann. Ist neben dem Blatt das Minus-Zeichen sichtbar, so wird hinter jedem Link die Information eingeblendet, zu welchem Pack er führt. Bei sichtbarem Plus-Zeichen fehlt diese Information.

Rollen und Administratoren

Wenn alle lizenzrechtlichen Fallstricke beseitigt sind, können die restlichen Punkte des Setup-Menüs abgearbeitet werden. Hinter den Punkten "Rollen" und "Administratoren" verbirgt sich eine umfangreiche Rollen- und Rechteverwaltung.

Unter "Administratoren" können einzelne Nutzer mit ihren Zugangsdaten eingerichtet werden. Hier können ihnen auch gezielt Rechte zum Zugriff auf einzelne Funktionen und/oder Zielsysteme zugeteilt werden. Da bei einer direkten Vergabe der Rechte jedoch schnell die Übersicht verloren geht, besteht unter "Rollen" die Möglichkeit, Administrationsrollen mit bestimmten Rechten zu definieren.

Die Möglichkeiten der Rechtevergabe unterscheiden sich dabei nicht von der direkten Zuweisung. Die definierten Rollen können anschließend den Administratoren oder auch anderen Rollen zugeordnet werden.

Benachrichtigungsmethoden

Die Zugriffsdaten zu einem SMTP-Server für den Versand von Nachrichten können unter "Benachrichtigungsmethoden" hinterlegt werden. Darüber hinaus besteht dort auch die Möglichkeit, alternative Methoden für die Benachrichtigung in Form von Betriebssystem-Befehlen oder PL/SQL-Prozeduren einzurichten. So können über eigene Skripte beliebige Aktionen ausgeführt werden. Diese Benachrichtigungsmethoden können später bestimmten Ereignissen zugeordnet werden. Das dient vor allem der Weiterleitung der Meldungen an fremde Systeme.

Patching Setup

Patching Setup erlaubt es dem Benutzer, die Zugangsdaten zu einem Metalink-Account im System zu hinterlegen und festzulegen, wie auf diesen Account zugegriffen werden kann.

Blackouts

Blackouts bezeichnen im Grid Control Auszeiten bezüglich der Überwachung von Zielsystemen. Durch die Festlegung eines Blackouts kann so z. B. die Verfälschung der Statistiken bei einer gezielt durchgeführten Wartungsarbeit verhindert werden. Die Konfigurationsmöglichkeiten der Blackouts sind sehr vielfältig. So kann genau festgelegt werden, welche Hosts bzw. welche Ziele auf einem Host für welchen Zeitraum nicht überwacht werden sollen und ob ein Blackout einmalig ist oder sich in regelmäßigen Abständen wiederholt.

Registrierungskennwörter

Über Registrierungskennwörter wird festgelegt, welcher Agent sich am OMS anmelden kann. Ein solches Passwort kann persistent sein und somit von mehreren Agenten genutzt werden oder für den einmaligen Gebrauch durch einen Agenten angelegt werden und nach Verwendung automatisch verworfen werden. Beide Arten von Kennwörtern können mit einem Ablaufdatum versehen werden, bis zu dem sie gültig sind.

Policies

Die Überwachung der Zielsysteme geschieht im EM anhand so genannter Policies. Eine Policy beschreibt dabei die zulässigen Werte oder Zustände eines Parameters und den Grad, wie kritisch das Verlassen des definierten Wertebereiches ist. Für jedes zu überwachende Ziel müssen solche Policies festgelegt werden. Da bei gleichartigen Zielen häufig auch identische Policies verwendet werden, besteht unter dem Menüpunkt "Überwachungsvorlagen" die Möglichkeit, die Policies eines Zieles als Vorlage zu übernehmen und diese Vorlagen auch auf andere Ziele desselben Typs anzuwenden. Auf eine sinnvolle Nutzung der Policies werden wir detailliert in einem eigenen Artikel eingehen.

Library für fehlerbehebende Maßnahmen

Unter "Library für fehlerbehebende Maßnahmen" kann ein Administrator Aktionen festlegen, die im Falle einer Policy-Verletzung als automatisierte Sofortmaßnahme ausgeführt werden können. Welche Aktion bei welcher Policy-Verletzung ausgeführt wird, ist an anderer Stelle, bei der Definition der Policy, anzugeben. Hier wird zunächst lediglich ein Pool von möglichen Maßnahmen erstellt, auf die später zurückgegriffen werden kann. Die Möglichkeiten reichen dabei von einfachen Betriebssystembefehlen über das Ausführen von SQL- oder RMAN-Skripten bis hin zu Multi-Task-Aktionen, die bei Eintritt eines Ereignisses unterschiedliche Dinge für verschiedene Ziele ausführen können. Der Phantasie des Administrators sind hier kaum Grenzen gesetzt.

Plug-Ins

Da Oracle den EM Grid Control gerne als alleiniges Monitoring- und Management-Tool auch in heterogenen Serverlandschaften sehen möchte, besteht über das Einbinden von Plug-Ins die Möglichkeit, auch Systeme anderer Hersteller einzubinden.

Oracle selbst stellt eine Reihe solcher Plug-Ins z. B. für IBM DB2 Datenbanken, Microsoft SQL Server oder auch JBoss Application Server zur Verfügung. Darüber hinaus besteht aber auch die Möglichkeit, dass Drittanbieter oder sogar Anwender selbst Plug-Ins für den EM erstellen, um weitere Systeme einzubinden. Plug-Ins werden im EM über den Menüpunkt "Management Plug-Ins" eingebunden.

Oracle Client System Analyzer

Mit dem Oracle Client System Analyzer können über eine spezielle Webseite mit Hilfe eines Java-Applets umfangreiche Informationen über Client-Systeme gesammelt und ausgewertet werden. Dazu kann der Client die vom OMS bereitgestellte Seite direkt aufrufen oder darauf umgeleitet werden.

Die gesammelten Informationen umfassen unter anderem Details zum Patch-Stand des Betriebssystems, eine Liste der im System registrierten Software und Informationen über die Hardware des Clients. Dies kann z. B. genutzt werden, um zu prüfen, ob ein Client die Anforderungen zur Nutzung der Oracle Collaboration Suite oder anderer Software erfüllt.

Voreinstellungen

Nach Abschluss des Setups können unter "Voreinstellungen" einige weitere Konfigurationen vorgenommen werden, die die tägliche Arbeit mit dem EM vereinfachen. Unter "Allgemein" können eine oder mehrere E-Mail-Adressen für Benachrichtigungen hinterlegt werden. Dabei kann für jede Adresse gewählt werden, ob die Nachrichten in einem kurzen oder langen Format versendet werden sollen.

Die Einstellung, welche Ereignisse eine Benachrichtigung auslösen und an welche Adresse diese versendet werden sollen, erfolgen unter dem Menüpunkt "Benachrichtigung", der sich wiederum in die Unterpunkte "Regeln" und "Ausführungsplan" unterteilt.

Regeln und Ausführungsplan

Regeln beschreiben hier Ereignisse, die zum Versand einer Benachrichtigung führen. Eine kleine Sammlung solcher Regeln ist bereits vordefiniert und kann abonniert werden. Der Nutzer kann aber auch eigene Regeln definieren. Die diesbezüglichen Konfigurationsmöglichkeiten sind recht umfangreich.

Zunächst wird festgelegt, für welche Zielsysteme eine Regel gültig ist, danach, durch welche Ereignisse eine Benachrichtigung ausgelöst wird. Dies können z. B. verschiedene Stati des Agenten auf dem jeweiligen Host, vordefinierte oder selbst erstellte Metriken, Policies oder Jobs sein. Abschließend muss entschieden werden, welche der im Setup angelegten Benachrichtigungsmethoden verwendet werden soll und ob die Regel öffentlich ist und somit auch von anderen Administratoren abonniert werden kann.

Über den Ausführungsplan kann ein Anwender genau steuern, welche seiner hinterlegten Mailadressen zu welchem Zeitpunkt gültig sein soll. Prinzipiell können hier sehr komplexe Schichtpläne mit mehrwöchigen Rotationszyklen angelegt werden. Sinnvoller dürfte es aber sein, z. B. tagsüber eine Standardadresse zu verwenden und die Nachrichten nachts und am Wochenende an eine spezielle Bereitschafts-Mailadresse zu senden, die eventuell automatisch einen Pager-Alarm auslöst.

Bevorzugte ID-Daten

Unter dem Menüpunkt "Bevorzugte ID-Daten" können für jedes Ziel Standard-Benutzerkennungen und Passwörter hinterlegt werden. Der Umfang der Konfigurationsmöglichkeiten hängt hier von der Art des Ziels ab. Für Hosts besteht beispielsweise die Möglichkeit, die Zugangsdaten eines normalen und eines privilegierten Users einzurichten. Verwendet werden die hier hinterlegten Daten unter anderem zur Ausführung von im Setup konfigurierten, fehlerbehebenden Maßnahmen oder für diverse über die Administrationsoberfläche ausführbare Aktionen auf den Zielsystemen.

Ziel-Unterregister

Der Menüpunkt "Ziel-Unterregister" erlaubt es schließlich, ein wenig Einfluss auf die Oberfläche des EM zu nehmen und festzulegen, welche Zielsystemtypen unterhalb des Menüpunktes "Ziele" aufgeführt werden sollen.

Fazit und Ausblick

Das Aufsetzen des EM Grid Control war in der ersten Version (10.1.) sehr aufwändig und fehleranfällig. Die Stabilität hat sich mit 10.2 eindeutig verbessert. Entscheidend für einen sinnvollen Einsatz ist ein ausgiebiges Customizing, das über Voreinstellungen und Setup beginnt. Weitere Einstellungen müssen später unter Ziele, Alerts und Policies vorgenommen werden. Hier müssen vor allem die Policies und Alerts gepflegt werden. Über dieses Vorgehen werden wir in weiteren Folgen dieser Serie berichten. Der nächste Artikel dieser Reihe wird sich mit dem Thema "Administration von Oracle Datenbanksystemen mit Hilfe des EM Grid Control" befassen.

Roman Peters (info@ordix.de).