IzzySoft

• Person
• Services
• Referenzen
• Software
• Oracle
• Impressum

Oracle 10g GridControl Installation

Die Überwachung von Datenbanken und Servern ist für Administratoren eine der wichtigsten Aufgaben. Speziell für Oracle Datenbanken stellt sich hier die Frage: Warum nicht gleich ein Oracle Tool dafür hernehmen? Der Hersteller kennt seine Software doch (hoffentlich) am besten, und weiß (hoffentlich), worauf es ankommt!

Wer obige Frage nun mit "Klar doch!" beantwortet, fragt sich als nächstes sicherlich: DBControl kommt doch gratis mit der Datenbanksoftware. Brauche ich wirklich GridControl?

Diese und andere Fragen werden (hoffentlich) in diesem Artikel beantwortet.

Worum es hier geht

Der Titel des Artikels und das Vorwort lassen es ja bereits erahnen: Es geht um das Ob und Wie der Installation. Wir benutzen dafür eine bereits existierende Datenbank (auf das "Warum" kommen wir noch) für das Repository, und arbeiten auch wiederum unter Linux (RHEL / CentOS).

Worum es hier NICHT geht

Oh ja, immer das gleiche mit dem Autoren: Der Windoze-Kram bleibt außen vor (es geht hier schließlich um richtige Server, und wir sprachen gerade von RedHAT, nicht RedMOND). Außerdem sprechen wir auch nicht über die Option "Standard-Installation mit einer neuen Datenbank" (im Installer: "Installing GridControl with a new database") – auf das "Warum" kommen wir, wie bereits erwähnt, jedoch zu sprechen.

Inhalt

• Warum GridControl?
  • Erste Kritiken an GridControl
  • Vorsicht mit den Alarmen
• Voraussetzungen
  • Allgemein
  • Zusätzliche Anforderungen an die Hardware
  • Zusätzliche Software-Anforderungen
  • Umgebung
  • Datenbank
    • Berechtigungen
    • Konfiguration
    • Verschiedenes
• Installieren der GridControl Software
  • Starten des Installers
  • Der Installationsprozess
• Patches installieren
  • Vorbereitungen
    • Download und Entpacken
    • Stoppen der EM Services
  • Patches installieren
  • Services prüfen
• Nacharbeiten und Anmerkungen
  • OMS
    • Services
    • Port-Sicherheit
  • Remote Agents
    • Vor der Installation
    • Push Install
    • Pull Install
    • Agenten absichern
  • Nicht verfügbare Services
  • Discover der Datenbanken
    • Normale Datenbanken
    • DataGuard Datenbanken
  • Policies
    • Abschalt-Kandidaten
    • Auszuschließende Ports
    • Well Known Accounts
    • Verschiedene Policies und Metriken
    • Permissions
    • Policy Templates
• Troubleshooting
  • Installation und Konfiguration
    • Unbekanntes Ziel: generic_mom_managed_host
    • Fehler bei der "Pull-Installation" des 10.2.0.4 Agenten
    • Agenten neu installieren
  • Alarme und Policies
    • Grid meldet der Listener sei "down" – lsnrctl ist anderer Meinung
    • PLS-00201: identifier 'MGMT_CNTR_TT.CLEAN_UP_OLD_TICKET_RECS' must be declared
    • Warnungen und Fehler, weil eine Standby-Datenbank "nicht geöffnet" ist
    • Probleme mit der Open Ports Policy
    • Alert: Fehler – Missing Properties
    • Zahlreiche "Erfassungsfehler" mit ORA-00600
    • Alerts: "Benutzer SYS angemeldet von …"

Warum GridControl?

Mit dem Software-Paket zur Erstellung (und Verwaltung) einer Oracle 10g Datenbank kommt auch ein Dienst namens DBConsole quasi gratis mit, welches GridControl recht ähnlich ist – jedoch nicht unbedingt eine Enterprise Lizenz erforderlich macht. So stellt sich die Frage: Reicht das nicht? Wozu brauche ich GridControl?

Dafür mag es eine Reihe von Gründen geben. Zwei mögliche sollen hier genannt werden:

Mit DBControl lässt sich nur jeweils eine Datenbank verwalten – man braucht also pro Datenbank eine komplette Installation, und muss die Oberfläche dann auch jeweils per Web-Browser auf dem jeweiligen Server aufrufen. Keine Chance also, alle Datenbanken auf einen Blick zu sehen – und genau das ist einer der großen Vorteile von GridControl: Ich muss mir nur eine Web-Adresse merken, und dort finde ich auch als erstes eine Übersicht über die Verfügbarkeit aller Datenbanken und Dienste, sowie etwaige Fehler. Von hier aus kann ich auch alle "angeschlossenen" Datenbanken verwalten.

"Des einen Eule ist des anderen Nachtigall": Mit dem Enterprise Manager Grid Control kommen auch schärfere Sicherheitsregeln. Das erhöht natürlich auf der einen Seite die Sicherheit (man wird auf wesentlich mehr potentielle Lücken aufmerksam gemacht). Wen es auf der anderen Seite bei verschiedenen Punkten ("Metriken") nervt, kann diese aber auch anders konfigurieren oder die entsprechenden Warnungen einfach abschalten.

Erste Kritiken an GridControl

… kommen schon beim Download der Software vom Oracle Server auf: Die aktuelle Version ist die 10.2.0.4 - das dazugehörige Archiv ist ca. 1 GB groß. Nach dem Herunterladen stellt man fest: Es enthält nichts als Patches, das ReadMe weist darauf hin, dass das Paket eine vorige Version voraussetzt.

Wer jetzt Version 10.2.0.3 herunterlädt, darf vorigen Absatz nochmals lesen: Wiederum 1 GB und nur Patches.

Laden wir uns also Version 10.2.0.2 – gleich 1.5 GB groß. Ja, endlich haben wir den Installer. Das Paket genauer unter die Lupe genommen: Etwa ein Drittel davon ist eine Oracle Datenbank in Version 10.1 – hoffnungslos veraltet (wir sind bereits bei 10.2.0.4 mittlerweile) und unnütz: Wenn ich schon eine Datenbank habe, brauche ich diesen Teil nicht – es sei denn, ich habe eine noch ältere Version, die für das Repository nicht unterstütz wird (also älter als 9.2.0.6). In diesem Falle würde ich mir doch aber lieber eine aktuelle Version separat herunterladen, oder? Also ca. 1GB für nix – sofern das Patch-Paket ähnlich aufgeteilt ist.

Die Idee dahinter mag sein, zwei (oder mehr) Fliegen mit einer Klappe zu schlagen: Wer schon eine Vorgängerversion installiert hat, kann diese hiermit patchen. Wer nicht, kann sich ja eine Vorgängerversion installieren. Aus Sicht des Herstellers recht bequem – aber nicht unbedingt kundenfreundlich. Abgesehen davon führt das u.U. bei "Zeitknappheit" in einigen Fällen dazu, dass die Patches nach der Installation erst gar nicht mehr eingespielt werden, weil die Zeit dazu "fehlt" – und es bleiben Sicherheitslöcher zurück. Oder es kommt zu zusätzlichen Problemen durch den zusätzlich nötigen Schritt des Patchens, die definitiv vermeidbar wären …

Hier sollte Oracle dringend nachbessern. Bei den Preisen für eine Enterprise Lizenz ist das m. E. nicht zuviel verlangt.

Vorsicht mit den Alarmen

GridControl ist ein mächtiges Werkzeug für den Administrator, und kann ihm definitiv die Arbeit erleichtern – dennoch ist es in einigen Punkten mit Vorsicht zu genießen. Dies betrifft insbesondere die Alarme: Während bei einem Alarm wegen eines offenen Ports 1521 jedem DBA sofort klar sein sollte, dass es sich hier mit dem Oracle Listener um eine für den Betrieb unabdingbar nötige Komponente handelt, und daher eine Ausnahmeregel definiert werden muss (und eben nicht der Port geschlossen werden sollte) – sieht das bei einem Alarm aufgrund "gefährlicher" Berechtigungen für Public schon anders aus: Es wirkt plausibel, diese zu entziehen – doch damit macht man sich u. U. die Datenbank teilweise unbrauchbar (ich gehe an anderer Stelle noch näher darauf ein), da Oracle sich an anderer Stelle blind darauf verlässt, dass eben diese Berechtigungen vorhanden sind. Hier ist definitiv Nacharbeit seitens Oracle nötig: Zum einen die Alarme bzw. zumindest deren Hilfeseiten etwas aussagekräftiger und detaillierter zu gestalten – und zum anderen sich nicht blind auf etwas zu verlassen, worüber man sich an anderer Stelle dann beschwert (hier: Bei der Installationion von Oracle Text die notwendigen Berechtigungen explizit zu vergeben, statt sich implizit auf deren Existenz zu verlassen).

Voraussetzungen

Allgemein

Wie bereits auf der vorigen Seite erwähnt, gehen wir davon aus, dass bereits eine Oracle 10g Datenbank für das Repository erstellt wurde. Obwohl diese sich durchaus auf einer anderen Maschine befinden kann (wie Oracle es übrigens auch empfiehlt), kann sie sich ebenso auf dem selben Server befinden, auf dem wir nun die Management-Software installieren wollen. Die Anforderungen sind somit die gleichen, wie sie bereits für die Datenbank selbst gelten – zuzüglich einiger weiterer, die wir hier beschreiben:

Zusätzliche Anforderungen an die Hardware

• Plattenplatz: zusätzliche 2.5GB für die Grid Software
• RAM: Mindestens 2GB

Zusätzliche Software-Anforderungen

Wir benötigen u.a. auch die Pakete:

• sysstat
• wget

Anmerkung: Oracle nennt als Anforderung außerdem das Paket control-center, welches allerdings eine ganze Kette von Abhängigkeiten nach sich zieht (es wird fast eine komplette Gnome-Umgebung inklusive Evolution u.a.m. installiert). Ich fand dies kontraproduktiv, und habe das Paket daher nicht installiert. Weder hat sich später der Installer darüber beschwert (und der prüft ja nochmals gründlich, ob auch alles da ist) – noch konnte ich bisher irgendwelche "Folgefehler" feststellen. Das heißt nun freilich nicht, dass man das Paket auf jeden Fall weglassen kann – es ist nur ein Hinweis, dass dies wohl möglich ist. Die Entscheidung steht jedem frei.

Umgebung

Nein – die Frage ist jetzt nicht, wie weit der Kühlschrank mit dem Bier vom Server entfernt ist! Gefragt ist die Betriebssystem-Umgebung: Hier brauchen wir auf jeden Fall den Benutzer nobody, der bei RedHat schon per default vorhanden ist. Um auf "Nummer sicher" zu gehen, kann man entweder in der Datei /etc/passwd nachschauen – oder an der Shell den Befehl id nobody absetzen, der die user_id (eine Zahl) ausgeben sollte.

Wie üblich, gibt es im Verlauf der Installation auch wieder das eine oder andere Skript als Benutzer root auszuführen – in unserem Falle gleich zwei Mal. Und dann noch jeweils einmal auf jeder Maschine, auf der ein Agent installiert werden soll.

Datenbank

Berechtigungen

Die echt schrägen Sachen gleich zuerst, über die ich bei der Installation gestolpert bin: Obwohl DBControl immer darauf hingewiesen hat, dass man doch bitte dem Benutzer PUBLIC die EXECUTE Rechte auf die utl_* Pakete entziehen solle – geht die Installation der Grid-Software voll in die Hose, so jemand diesen Hinweis befolgt. Um nach entsprechender Korrektur und erfolgreicher Installation exakt selbiges wieder zu bemängeln! Die Logik ist nicht ganz klar (tja, wir reden ja schließlich auch nicht von "Logical", sondern von "Oracle" – und Orakel haben sowas nun einmal an sich) – tun wir trotzdem, was von uns verlangt wird, und tun folgendes vor der Installation auf der Repository-Datenbank:

sqlplus> GRANT EXECUTE ON utl_smtp TO public;
sqlplus> GRANT EXECUTE ON utl_tcp TO public;
sqlplus> GRANT EXECUTE ON utl_file TO public

Sobald die Installation später erfolgreich abgeschlossen ist, und GridControl läuft, machen wir das wieder rückgängig (REVOKE..FROM public), und verpassen zur Sicherheit die entsprechenden Rechte dem Benutzer SYSMAN, der für das GridControl zuständig ist (GRANT..TO sysman).

Konfiguration

Die RedoLogs sollten 100MB groß sein. Auch muss das Package dbms_shared_pool installiert sein – falls das nicht der Fall ist, lässt sich dies (als Benutzer SYS) wie folgt bewerkstelligen:

sqlplus> @?/rdbms/admin/dbmspool.sql

Schließlich gilt es, auch die Einstellungen in der init.ora zu prüfen. Hier brauchen wir u.a.:

job_queue_processes     >= 10
db_block_size            = 8192
timed_statistics         = TRUE
statistics_level         = TYPICAL
open_cursors            >= 300
session_cached_cursors  >= 200
aq_tm_processes         >= 1
undo_management          = AUTO
undo_retention          >= 10800
processes               >= 150
log_buffer               = 1 M
pga_aggregate_target    >= 256 M
sga_target              >= 512 M
_b_tree_bitmap_plans     = FALSE

Verschiedenes

• DBControl darf in der Repository-Datenbank nicht konfiguriert sein – GridControl und DBControl können nicht miteinander. Sollte DBControl konfiguriert sein, wird man es als Betriebssystem-Benutzer oracle mit der richtig gesetzten ORACLE_SID wie folgt wieder los: $ORACLE_HOME/bin/emca -deconfig dbcontrol db -repos drop
• Um Fehler bei der Installation (und im späteren Betrieb) zu vermeiden, sollte der $TNS_ADMIN/listener.ora folgende Zeile hinzugefügt werden, sofern sie nicht bereits dort ist:
  SUBSCRIBE_FOR_NODE_DOWN_EVENT_<listener-name>=OFF
  (<listener-name> ist hier mit dem Namen des verwendeten Listener zu ersetzen – per default wäre das LISTENER). Andernfalls blockiert der Listener einen Port, den GridControl benötigt. Anschließend muss der Listener neu gestartet werden (lsnrctl stop && lsnrctl start).
• Wer will, kann jetzt auch noch die Default-Ports für die GridControl Services anpassen – indem er die Datei response/staticports.ini im GridControl Installationsverzeichnis entsprechend editiert.

Installieren der GridControl Software

Starten des Installers

Als Benutzer oracle auf dem Rechner angemeldet, wo die Grid Software installiert werden soll, entpacken wir die Installationsarchive in ein leeres Verzeichnis und wechseln in selbiges. Dort können wir nun den Installer aufrufen: ./runInstaller. Detaillierte Hinweise für das weitere Vorgehen finden sich hier (und hier) – für diejenigen, denen die Beschreibung hier zu knapp sind.

Ach ja: Da der Installer (wie immer) eine grafische Umgebung voraussetzt, sitzt man entweder direkt an der betreffenden Maschine – oder hat für entsprechendes "X Forwarding" und Export der DISPLAY Variable gesorgt, z. B. indem man die SSH Option -X bzw. -Y beim Aufbau der Session verwendet.

Der Installationsprozess

Ist der Installer gestartet, fragt er zunächst nach der Art der Installation. Hier wählen wir "Enterprise Manager 10g Grid Control Using an Existing Database", und klicken auf "Next". Auf der zweiten Seite sind nun die Details für die Repository-Datenbank einzutragen. Dann klicken wir auf den Button "Prefill Tablespace Locations", damit die richtigen Pfade für die Datendateien ermittelt werden (als Nebeneffekt wissen wir bei Erfolg sogleich, dass die Angaben zur Datenbank stimmig sind). Passt alles, gilt es wiederum, auf den "Next" Button zu klicken.

Auf der nun folgenden Seite sollten wir auf jeden Fall die EMail-Adresse sowie den SMTP-Server eintragen, damit wir im Problemfall auch benachrichtigt werden. Alles weitere ist optional: Wer will, dass GridControl "nach Hause telefonieren" kann, trägt noch die MetaLink- sowie ggf. die Proxy-Daten ein. Und wieder ein Klick auf den "Next" button.

Jetzt kommen die Passwörter. Hier schlagen zum ersten mal die restriktiveren Policies zu: Mindestens 5 Zeichen, das erste ein Buchstabe, und mindestens eines der folgenden eine Ziffer. Und wieder klicken wir - auf "Next".

Es folgt noch ein Bildschirm mit der Übersicht über das, was wir da gerade installieren wollen (bzw. sollen), und nach einem letzten Klick auf "Next" startet schließlich die Installation. Mit etwas Glück läuft sie auch, Dank unserer Vorbereitungen, sauber durch – und wir können den Installer beenden. Zu diesem Zeitpunkt laufen bereits alle Services des Enterprise Managers.

Patches installieren

Vorbereitungen

Download und Entpacken

Es bedarf eigentlich keiner besonderen Erwähnung – aber der Vollständigkeit halber sei es dennoch gesagt: Natürlich muss zunächst das Patch-Archiv von der Oracle Seite heruntergeladen und in ein leeres Verzeichnis entpackt werden. Anschließend löschen wir alles – bis auf die Datei p3731593_10204_LINUX.zip. Den Rest brauchen wir nun wirklich nicht: 373596.zip und 3822442.zip sind für das Patchen bereits "verteilter" Agenten gedacht (wir haben noch keinen verteilt), und die beiden p4329444*.zip Dateien enthalten nur Patches für die von uns nicht benutzte 10gR1 Datenbank (wie man sieht, sparen wir also hier wieder ein paar Schritte). Wenn man den Umfang anschaut: Über 50% umsonst heruntergeladen …

Also entpacken wir noch p3731593_10204_LINUX.zip, und erhalten ein neues Verzeichnis: In 3731593 finden sich nun die für das Patchen benötigten Dateien.

Stoppen der EM Services

Jetzt müssen wir alle Services des Enterprise Managers stoppen. Dabei helfen uns folgende drei kleine Befehle:

$EM_HOME/bin/emctl stop oms
$EM_HOME/opmn/bin/opmnctl stopall
$AGENT_HOME/bin/emctl stop agent

$EM_HOME ist dabei das ORACLE_HOME des OMS (üblicherweise ein Verzeichnis namens "oms10g", und bei uns parallel zum normalen ORACLE_HOME als em102/oms10g zu finden), das $AGENT_HOME an gleicher Stelle als agent10g.

Patches installieren

Also rein in das oben erstellte Verzeichnis namens 3731593, und den ./runInstaller aufgerufen. Auf der ersten Seite wählen wir zunächst das Oracle Home für den OMS ("oms10g") aus, und gehen auf die nächste Seite. Dort prüfen wir, ob auch die korrekte Datenbank gefunden wurde (die mit unserem Repository), und geben das Passwort für den Oracle-Benutzer SYS an. Noch ein paar dumme Fragen (nichts weiter wichtiges), und die Installation läuft. Für etwa 15 Minuten oder so. Ist alles sauber durchgelaufen, bleibt uns nur noch der Button "Finish".

Und ein erneuter Start des ./runInstaller. Diesmal geht es dem Agenten an den Kragen ("agent10g"). Eine Seite weniger (es wird keine Datenbank aktualisiert), und auch die Installation geht schneller über die Bühne. Was bleibt, ist wieder der "Finish" Button.

Services prüfen

Stoppen kann der dumme Installer sie nicht – aber nach dem Patchvorgang hat er sie alle schon wieder gestartet. Wo nicht, hilft folgendes:

$EM_HOME/bin/emctl start oms
$EM_HOME/opmn/bin/opmnctl startproc ias-component=WebCache
$AGENT_HOME/bin/emctl start agent

Zum Prüfen statt start einfach status verwenden. Eine dumme Meldung gibt es bei dem Versuch, den WebCache zu starten: no processes matched this request – Was immer das auch soll: Dieser Befehl stammt direkt aus dem Grid Handbuch auf den Oracle Seiten …

Nacharbeiten und Anmerkungen

OMS

Services

Unmittelbar nach dem Installations- sowie dem Patchprozess startet der Installer (ohne darum gebeten worden zu sein) gleich eine ganze Reihe von Diensten, die wir u. U. gar nicht alle benötigen. Sicher brauchen wir sowohl den OMS als auch die Agents – aber nicht unbedingt alle IAS Komponenten. Welche davon existieren, und ob diese nun auch bereits laufen, verrät uns ein $OMS_HOME/bin/opmnctl status -l. Aus dieser Liste gehören nur drei zur Grundausstattung:

1. OC4J_EM
2. OC4J_EMPROV
3. HTTP_SERVER

Diese sollten also auf jeden Fall bei einem Serverstart mitgestartet werden – alle anderen sind optional (und nach Bedarf einzubinden). Dabei ist die Reihenfolge durchaus von Bedeutung. Gesetzt den Fall, wir brauchen die anderen Dienste nicht, sähe ein Start aller benötigten Komponenten wie folgt aus:

$OMS_HOME/bin/emctl start oms
$OMS_HOME/opmn/bin/opmnctl startproc process-type=OC4J_EM
$OMS_HOME/opmn/bin/opmnctl startproc process-type=OC4J_EMPROV
$OMS_HOME/opmn/bin/opmnctl startproc process-type=HTTP_Server
$AGENT_HOME/bin/emctl start agent

Wer sich jetzt wundert, wo da nun OC4J_EM und HTTP_Server geblieben sind: Die wurden beide implizit von emctl start oms mit erwischt. Das Herunterfahren geht nun so:

$OMS_HOME/bin/emctl stop oms
$OMS_HOME/opmn/bin/opmnctl stopall
$AGENT_HOME/bin/emctl stop agent

Port-Sicherheit

Während obige Schritte bereits die Liste der unnötig geöffneten Ports verkleinert (indem wir die entsprechenden Services erst gar nicht starten), bleiben immer noch ein paar Kandidaten übrig – im Wesentlichen HTTP Ports. Diese (verbliebenen) können wir leider nicht so ohne weiteres schließen – jedoch können wir den Zugriff unterbinden, und zwar in der Konfiguration des Webservers.

Bevor wir dies jedoch tun, muss sichergestellt sein, dass wir die Agenten nicht gleich mit aussperren – diese können u.U. noch auf unsicheres HTTP zurückgreifen. Also **unbedingt zuerst hier prüfen!

Alles klar soweit? Also gut. Die beiden betroffenen Dateien (siehe auch Metalink Note 452290.1) heißen $OMS_HOME/sysman/config/http_em.conf und http_em.conf.template (letztere überschreibt erstere immer dann, wenn wir die Sicherheitseinstellungen beim OMS mit secure lock ändern). Um die richtigen Abschnitte zu finden, fragen wir zuerst einmal beim OMS nach: <OMS HOME>/bin/opmnctl status -l verrät uns u.a. auch, welche Ports für HTTP benutzt werden. Für diese suchen wir uns nun die passenden Virtual Host Blöcke in den Konfigurationsdateien, und passen sie ein wenig an. Das könnte dann in etwa so aussehen:

<VirtualHost *:4889>
...
  <Location /em/console>
    order deny,allow
    Deny from all
  <Location>

Richtig geraten: Deny from all ist hier der Schlüssel, der jedem den Zugang verbietet – also den Agenten wie den DBAs.

Remote Agents

Höchstwahrscheinlich haben wir zumindest eine Datenbank auf einem anderen Host, oder wollen einen anderen Host mit überwachen. Das setzt voraus, dass auf selbigem auch ein Agent läuft – aber den müssen wir auch erst einmal installieren. Natürlich können wir jetzt unser gesamtes Installationsverzeichnis auf jenen Rechner kopieren, und wiederum den Installer bemühen - aber es gibt auch noch mindestens zwei Alternativen:

Vor der Installation

Okay - wir haben alles installiert, gepatcht und konfiguriert: Was denn jetzt noch? Eigentlich nichts – nur dass für eine Installation der Agenten auf anderen Rechnern nach wie vor nur die Version 10.2.0.1 zur Verfügung steht. Warum dies trotz des Patchens von OMS und Agenten-Installation so ist, kann ich nicht sagen …

Aber das bedeutet nichts weiter – außer weiteren 340MB für die Komplette 10.2.0.4 Agenten Installation](http://download.oracle.com/otn/linux/oem/10204/Linux_Grid_Control_agent_download_10_2_0_4_0.zip) von der Oracle Seite. Der Inhalt dieses Archivs muss sodann nach <OEM Home>/sysman/agent_download/10.2.0.4.0 entpackt werden (zumindest das enthaltene Verzeichnis linux samt Inhalt). Dann wird zwar nach wie vor Version 10.2.0.1 ausgerollt – aber im gleichen Lauf automatisch auf 10.2.0.4 gepatcht. Warum das so umständlich sein muss, weiß nur das Orakel …

Push Install

Push Install benötigt ein funktionierendes SSH Setup: Der Management Server muss Dateien auf den zu überwachenden Host kopieren und dort installieren können – und schließlich muss der Agent ja auch gestartet werden. Ist SSH noch nicht entsprechend eingerichtet, kann man dies mit dem Skript <OMS ORACLE_HOME>/sysman/prov/resources/scripts/sshUserSetup.sh nachholen.

Jetzt können wir die GridControl Webseite aufrufen (z. B.: https://<servername>:1159/em), auf den Tabe Deployments klicken, und dort auf den Link Agent Installieren. Es werden jetzt nochmals Benutzername und Passwort abgefragt, und schließlich wird die Software ausgespielt.

Der große Vorteil hier: Die gleichen Login-Daten vorausgesetzt, lässt sich mit einer einmaligen Aktion der Agent auf eine ganze Reihe von Hosts installieren.

Pull Install

Anders als beim Push Install, brauchen wir hier kein SSH Setup. Dafür muss aber wget auf dem Host verfügbar sein, auf dem wir den Agenten installieren wollen. Als entsprechender Benutzer (in der Regel oracle) dort angemeldet, führen wir nun folgendes aus:

oracle@remotehost> wget http://<emhost>:4889/agent_download/10.2.0.4.0/linux/agentDownload.linux
oracle@remotehost> chmod +x agentDownload.linux
oracle@remotehost> ./agentDownload.linux -m <emhost> -b <ORACLE_BASE> -r 4889

ORACLE_BASE gibt hier das Verzeichnis an, unterhalb dessen das AGENT_HOME angelegt wird. Wählen wir beispielsweise /home/oracle/em102, erhalten wir das Verzeichnis /home/local/em102/agent102 als AGENT_HOME. Hier hinein wird die Software automatisch installiert, und schließlich der Agent gestartet. Mit Version 10.2.0.4 muss auch der Port (üblicherweise 4889) für den Download angegeben werden (hier: -r 4889 – sonst fällt das Skript mit einer Fehlermeldung auf die Nase.

Ah ja: <emhost> ist der Rechner, auf dem der Enterprise Manager läuft – also der, wo wir gerade auf den vorigen Seiten die große Installation abgeschlossen haben.

Agenten absichern

Die Agenten transportieren einige sensitive Daten übers Netz – u. a. Passwörter. Das sollte möglichst nicht unverschlüsselt passieren – zumindest nicht, wo es eine Alternative gibt. Und die haben wir: Neben http gibt es schließlich auch noch https! Aber schauen wir zunächst einmal nach, wie der aktuelle Status Quo aussieht:

$AGENT_HOME/bin/emctl status agent

Zu beachten gilt es hier die Zeilen Agent URL und Repository URL. Beginnt der Wert hier bereits mit "https://", ist alles bestens (zumindest nach einem Pull Install ist dies in der Regel der Fall). Andernfalls müssen wir ein wenig nachhelfen:

$AGENT_HOME/bin/emctl secure agent

Ist dies für alle beteiligten Agenten geschehen, können wir den Management Server anweisen, nur noch Verbindungen gesichterter Agenten zuzulassen:

$OMS_HOME/bin/emctl secure lock

So – jetzt ist die Kommunikation der Agenten komplett verschlüsselt, sie transportieren keine Passwörter mehr im Klartext übers Netz. Aber wie sieht es mit den Menschen aus, die auf GridControl per Web zugreifen? Sie könnten noch immer – natürlich nur versehentlich – unverschlüsselt agieren. Aber das können wir jetzt wie oben beschrieben unterbinden.

Nicht verfügbare Services

Sind wir soweit gekommen, können wir schließlich einen Blick auf unsere Überwachungs-Konsole werfen: Mit dem Web-Browser öffnen wir die GridControl Konsole (z. B. https://<emhost>:1159/em) und schauen, was sich dort tut.

Haben wir uns für die "minimale" Anzahl an Services entschieden, wie [oben](#omserv] beschrieben, und auch schon das Starten/Stoppen geübt, fällt uns zuerst etwas "rote Farbe" auf: 3 Services sind als "Down" markiert. Haben wir also ein Problem? Nicht unbedingt. Der Agent hat festgestellt, welche Services installiert sind – und geht nun davon aus, dass diese auch benutzt werden müssen. So war es von Oracles Standard-Installation ja auch vorgesehen – und woher soll der Agent wissen, dass wir anderer Meinung sind, wenn wir es ihm nicht mitteilen?

Also tun wir das jetzt. Dafür klicken wir zuerst auf den Tab Ziele, auf der nächsten Seite sodann auf Application Server in der Zeile unmittelbar darunter. Falls der Prozess-Baum auf der Seite noch zugeklappt ist, klicken wir noch auf den Link Alle einblenden, und sehen nun u. a. auch unsere drei Problemkinder. Keinesfalls jetzt alle drei entfernen! Damit würden implizit auch Dienste gelöscht, die wir hier behalten wollen. Oracle hat sich nämlich hier "verzählt": 1+1=3 stimmt nicht ganz – es sind nur zwei Dienste "tot", das dritte ist die Gruppe, zu der sie gehören. Wir zupfen jetzt also lediglich "Blätter" von Baum, lassen aber die "Zweige" dran: Als erstes markieren wir die Radiobox des WebCache, klicken auf den Button Entfernen, und bestätigen alle dummen Fragen (ja, das soll gelöscht bzw. entfernt werden). Dann wiederholen wir das Ganze für das Blatt EnterpriseManager*_home.

Zurück auf der Startseite (Tab Standardverzeichnis), oder auch noch in der gerade betrachteten Liste, ist jetzt noch immer ein Service "Down". Das sollten wir jedoch zunächst ignorieren: Grid Control braucht ein wenig Zeit für die Aktualisierung. Kümmern wir uns also zunächst um die anderen Dinge – wenn wir damit fertig sind, sollte unser drittes Problemkind sich erholt haben.

Discover der Datenbanken

Oh ja, da ist schon einiges zu sehen – nur keine Datenbanken! Für selbige heißt es schlicht, sie seien in einem "unbekannten Zustand", weil es "Metric Errors" gäbe. Ein wenig irreführend – tatsächlich kann sich der Management-Server schlicht nicht bei diesen Datenbanken anmelden, weil er das Passwort nicht kennt. Mit anderen Worten: Werden die Datenbanken bereits richtig angezeigt, haben wir ein Sicherheitsproblem … Wie auch immer, gilt es das jetzt zu lösen.

Normale Datenbanken

Wir gehen also auf die "Homepage" der betreffenden Datenbanken (z. B. indem wir in der Klappbox des Such-Formulars "Database-Instance" auswählen, selbiges dann abschicken, und auf den Link der jeweiligen Datenbank klicken). Hier wählen wir den Link Konfiguration der Überwachung, der in der Regel im unteren Seitenbereich im Abschnitt Zugehörige Links zu finden ist, und tragen dort das richtige Passwort für den angegebenen Benutzer (meist "dbsnmp") ein. Ist dieser auf der Zieldatenbank gesperrt, muss diese Sperre noch aufgehoben werden (ALTER USER dbsnmp ACCOUNT UNLOCK). Ggf. müssen wir ihm dort auch erst einmal ein Passwort verpassen (ALTER USER dbsnmp IDENTIFIED BY passwort). Ein Klick auf Verbindung Testen verrät uns den Erfolg, und der Weiter Button speichert die Einstellungen schließlich. Ein wenig später sollten wir die Datenbankinformationen in der Konsole sehen können.

DataGuard Datenbanken

Ist die Datenbank Teil einer DataGuard Konfiguration (also eine Standby- oder zugehörige primäre Datenbank), müssen wir einen Benutzer mit SYSDBA Rechten angeben – sonst gibt es bei der Standby-DB nur die Oracle Fehlermeldung ORA-01033: insufficient privileges, da selbige ja nicht geöffnet ist (für die primäre gilt dies nach einem SwitchOver, weshalb wir sie ebenso konfigurieren sollten). Hierzu öffnen wir zunächst die Klappbox, in der jetzt "NORMAL" steht, und wählen "SYSDBA" aus. Jetzt können wir auch den Benutzer editieren, und tragen z.B. "SYS" ein. Der Rest geht, wie oben beschrieben.

Policies

Wird eine Policy verletzt, erhalten wir einen Alarm von GridControl. Das ist genau das, was wir auch erwarten. Allerdings erwarten wir sicher nicht, einen der folgenden Alarme zu erhalten:

• Offene Ports: 1521 (Oracle Listener), 3872 (Oracle Agent), 1159 (GridControl secure HTTP)
• Remote-Kennwortdatei und Benutzung von extern identifizierten Accounts in einer DataGuard-Konfiguration (das wird ja hier gebraucht!)

Aber genau sowas kommt – unter anderem … Also ist es eine der nächsten Aufgaben, Ausnahmeregeln zu erstellen (bzw. bestimmte Policies gleich ganz abzuschalten) - sonst finden wir die "echten Alarme" unter den ganzen Fakes nicht mehr heraus. Beides ist recht einfach – und kann entweder für jede Datenbank (und jeden Host) separat gemacht werden, oder mittels Templates gleich für mehrere "Ziele" auf einen Rutsch.

Vorgehensweise für einzelne Ziele: Auf der GridControl Homepage klicken wir auf den Link (Zahl) hinter "Kritisch" bzw. "Warnung" im Segment "Alle Ziele Policy-Verletzungen". Auf der folgenden Seite ist es dann der Link (wieder die Zahl) in der Spalte "Anzahl von Verletzungen" (und der Zeile mit der zu bearbeitenden Policy). Nun folgen wir am Ende der Seite dem Link "Policy-Regeleinstellungen bearbeiten" (unter "Zugehörige Links"), und schon kann es losgehen:

Abschalten einer Policy: Einfach in der ersten Klappbox ("Policy-Auswertung") "Deaktiviert" auswählen, und auf den OK Button klicken.

Ausnahmeregeln erstellen: So oft auf den Button Objekt hinzufügen (im Segment "Ausgeschlossene Objekte") klicken, wie wir Ausnahmen benötigen – und selbige dann in die aufgetauchten Eingabefelder eintragen. Und zu guter Letzt auch hier nicht den OK Button vergessen.

Abschalt-Kandidaten

Einige Policies schalten wir wohl besser gleich ganz aus – da sie außer unnötigen Alarmen nicht viel weiteres bringen:

Auszuschließende Ports

Für die Policy Offene Ports sollten wir zumindest folgende Ausnahmen definieren:

Well Known Accounts

Hier hat's wahrscheinlich den Benutzer OUTLN erwischt. Zu tun ist in diesem Falle lediglich folgendes: Als SYSDBA an der Datenbank anmelden, und zwei Zeilen absetzen:

sqlplus> ALTER USER outln PASSWORD EXPIRE;
sqlplus> ALTER USER outln ACCOUNT LOCK;

Verschiedene Policies und Metriken

Sicher gibt es noch eine ganze Reihe von Policies und Metriken, die einer Anpassung bedürfen. Nicht alle können hier diskutiert werden – zumal die meisten recht subjektiv sein dürften. Dennoch sollen einige allgemeine Fälle kurz erwähnt werden:

Permissions

Schon kurze Zeit nach der Installation wird man feststellen, dass es da ein paar Widersprüche zwischen den bei jeder Installation/Aktualisierung der Oracle Binaries auszuführenden Catalog-Skripten und den Policies von GridControl gibt: Die Catalog-Skripte geben dem Benutzer PUBLIC eine ganze Reihe von Rechten, über die sich GridControl hernach beschwert. Widerruft man nun diese Rechte gemäß der Anweisungen von GridControl, funktioniert hernach GridControl auch nicht mehr: Es hat sich nämlich bei der Installation darauf verlassen, dass eben diese Rechte existieren! Einige andere Dinge könnten nun ebenfalls im Argen liegen.

Hier handelt es sich um ein bereits seit Jahren bekanntes Oracle "Feature". Von Oracle kann eine Lösung dafür frühestens mit einem der nächsten Releases erwartet werden (ein entsprechender "Feature-Request" existiert). Also müssen wir uns derweil selbst darum kümmern:

Die einfachste Vorgehensweise (wie sie sicher auch Metalink Support vorschlagen wird) ist, die entsprechenden Metriken zu deaktivieren. Hätte ich das jedesmal gemacht, wenn Metalink dies empfahl, könnte ich GridControl jetzt deinstallieren: Von der angepriesenen Funktionalität wäre nicht viel übrig. Also kümmern wir uns besser darum, die Berechtigungen zu korrigieren. Bevor wir daran jedoch Hand anlegen, sollte der Metalink-Artikel 247093.1 konsultiert werden: Änderungen hier können unerwünschte Nebenwirkungen zeigen!

Nun ermitteln wir als erstes die "Bedürftigen":

-- some (optional) output formatting
COLUMN package FOR a10
COLUMN owner FOR a10
COLUMN objects FOR 999
COLUMN references FOR a10
COLUMN type FOR a10
SET feedback off
SET verify off

SELECT referenced_name package, owner, count(name) objects,referenced_owner references, referenced_type type
  FROM dba_dependencies
 WHERE referenced_owner IN ('SYS','PUBLIC')
   AND referenced_type IN ('PACKAGE','SYNONYM')
   AND referenced_name IN ('UTL_FILE','UTL_SMTP','UTL_TCP','UTL_HTTP','DBMS_JOB','DBMS_LOB')
   AND owner <> 'SYS' AND owner <> 'PUBLIC'
 GROUP BY referenced_name, owner, referenced_owner, referenced_type
 ORDER BY referenced_name, owner, referenced_owner, referenced_type;

SET feedback on
SET verify on

Die Ausgabe dieses Skriptes dürfte etwa so aussehen:

DBMS_JOB   DBSNMP           1 PUBLIC     SYNONYM
DBMS_JOB   SYSMAN           5 PUBLIC     SYNONYM
UTL_FILE   ORACLE_OCM       1 PUBLIC     SYNONYM
UTL_FILE   SYSMAN           1 PUBLIC     SYNONYM

Das heißt: bevor wir PUBLIC die Rechte enziehen, sollten wir:

• DBSNMP und SYSMAN execute auf DBMS_JOB und
• ORACLE_OCM sowie SYSMAN execute auf UTL_FILE

gewähren (bitte gemäß des jeweiligen Ergebnisses anpassen!). Es heißt weiterhin, dass die anderen aufgeführten Packages nicht betroffen sind – wir also anschließend getrost selbige Berechtigungen widerrufen können:

-- Grant necessary permissions explicitly
GRANT EXECUTE ON dbms_job TO DBSNMP;
GRANT EXECUTE ON dbms_job TO SYSMAN;
GRANT EXECUTE ON utl_file TO ORACLE_OCM;
GRANT EXECUTE ON utl_file TO SYSMAN;

-- Remove unsafe permissions from public
REVOKE EXECUTE ON dbms_job FROM PUBLIC;
REVOKE EXECUTE ON dbms_lob FROM PUBLIC;
REVOKE EXECUTE ON utl_tcp FROM PUBLIC;
REVOKE EXECUTE ON utl_smtp FROM PUBLIC;
REVOKE EXECUTE ON utl_http FROM PUBLIC;
REVOKE EXECUTE ON utl_file FROM PUBLIC;

-- "Repair" packages we possibly broke temporarily
@?/rdbms/admin/utlrp.sql

Der letzte Befehl lädt ein Skript, welches die gesamte Datenbank auf invalide Objekte untersucht, um sie auch gleich zu "reparieren". Es könnte durchaus nötig sein, dieses Skript ein paar Tage später nochmals laufen zu lassen.

Warnung: Aufgrund komplexer Verschachtelungen kann das Entziehen diverser Berechtigungen etliche Nebenwirkungen haben. So wurden in einigen Fällen auch zahlreiche Objekte des Benutzers SYS selbst invalid – obwohl alle Objekte, deren Berechtigungen wir PUBLIC entzogen haben, diesem selbst gehören. Auch CTXSYS ist als besonderes Problemkind bekannt: Hier ließen sich einige Packages nicht einmal mehr kompilieren, nachdem genannte Berechtigungen (direkt und auch über PUBLIC) wieder erteilt wurden.

Sollten also nach o.g. Vorgehen plötzlich "invalid objects" (sicher meist Package Bodies) auftauchen, die sich weder mit @?/rdbms/admin/utlrp.sql noch mit einem expliziten ALTER PACKAGE <package_name> compile wieder "validieren" lassen (wobei letzteres meist mit einer Meldung wie "malformed or corrupted wrapped unit" verbunden ist), bleibt noch folgender Ausweg: Die Suche nach dem "Create" Skript des betreffenden Objektes (meist eine *.plb Datei) und das Ausführen derselben im Kontext des entsprechenden Benutzers. Dies hat hier in den meisten Fällen doch noch zum Erfolg geführt.

Ein Beispiel dafür:

COLUMN owner FOR a15
COLUMN object_name FOR a30
COLUMN status FOR a10
COLUMN object_type FOR a15
SELECT owner,object_name,status,object_type
  FROM dba_objects
 WHERE status<>'VALID';

könnte als Ergebnis folgendes zeigen:

CTXSYS     DRVDOC                         INVALID   PACKAGE BODY

Normalerweise versucht man nun ein ALTER PACKAGE ctxsys.drvdoc COMPILE BODY – doch das schlägt in unserem Beispiel fehl ("compilation errors"). Auch ein @?/rdbms/admin/utlrp.sql lässt diesen Fehler unbeeindruckt. Anhand des "Owners" sehen wir, dass das Objekt zu CTX gehört - suchen wir also das zugehörige CREATE Statement in $ORACLE_HOME/ctx/admin/*: Ein grep -i "package body drvdoc" $ORACLE_HOME/ctx/admin/* verweist uns auf die Datei drvdoc.plb. Also ab an den SQL-Prompt, und mutig getippt:

ALTER SESSION SET current_schema ctx;
@?/ctx/admin/drvdoc.plb

Und siehe da - alles wieder in Ordnung. Jedenfalls meistens …

Policy Templates

Jeden dieser Schritte für jedes einzelne Ziel zu wiederholen, macht nicht gerade große Freude – aber das müssen wir ja auch nicht. Dafür gibt es Templates, die dann auf mehrere Ziele zugleich angewendet werden können:

Ein Klick auf den Link Setup (oben rechts über den Tabs) bringt uns auf eine Seite, auf der wir den Link Überwachungsvorlagen auswählen können. Da sicherlich noch keine Vorlagen existieren, nutzen wir zunächst den Button Erstellen zur Anlage eines neuen Templates. Nun können wir ein passendes (und am Besten auch nach obigen Regeln bereits angepasstes) Ziel auswählen, von dem wir Policies übernehmen wollen. Wir müssen letztendlich nicht alle Regeln von hier nehmen, und können selbst die ausgewählten bei Bedarf noch genauer anpassen, bevor wir schließlich die Policy speichern.

Nachdem wir nun unser(e) Template(s) erstellt haben, können wir diese(s) mittels des Buttons Anwenden auf ein oder mehrere Ziele übertragen.

Troubleshooting

Auch nach der Installation und dem Patchen kommt noch das eine oder andere Problem zum Vorschein. Im folgenden seien einige davon aufgelistet – zusammen mit möglichen Lösungen.

Installation und Konfiguration

Unbekanntes Ziel: generic_mom_managed_host

Problem: Die GridControl Startseite zeigt ein als generic_mom_managed_host genanntes unbekanntes Ziel an, dessen Status GridControl nicht ermitteln konnte.

Ursache: Es wird halt einfach alles mögliche installiert – auch wenn man es nicht unbedingt benötigt … MOM steht für Microsoft Operations Management – was vermutlich überhaupt nicht benutzt wird. Dieser Connector ermöglicht es dem OEM lediglich, Alarme von MOM zu empfangen – wird also MOM überhaupt nicht einsetzt, kann der Connector auch nichts connecten.

Lösung: Da wir ohne installiertes MOM auch auf diesen Connector gut verzichten können, entfernen wir ihn einfach:

• Auf den Link "unbekannt" klicken
• Auf "generic_mom_managed_host" klicken
• Auf "Connector Einstellungen" klicken
• "Microsoft Operations Manager Connector" auswählen
• Auf "Löschen" klicken
• Auf "Ja" klicken

Fehler bei der "Pull-Installation" des 10.2.0.4 Agenten

Problem: Unter Benutzung der "Pull-Methode" soll der aktuelle Agent auf einem Host installiert werden. Per wget wurde das Skript dazu (agentDownload.*) erfolgreich heruntergeladen. Dessen Ausführung resultiert jedoch nicht in einem installierten Agenten – sondern in einem Fehler 404: Not Found.

Ursache: Ein Blick in <OMS Home>/sysman/agent_download/10.2.0.4 auf dem OMS Host zeigt uns, dass dort außer diesem Skript nur noch eine Textdatei in einem anderen Unterverzeichnis liegt – und nicht, wie im vergleichbaren 10.2.0.2 Verzeichnis, sämtliche benötigten Dateien. Installation und Patch wurden jedoch für beides, OMS und Agent, durchgeführt.

Lösung: Wer auf dieses Problem stößt, hat wohl diesen Abschnitt über einen zusätzlichen Download verpasst – also zurück und nachlesen ;)

Sieht ganz danach aus, als würde Oracle ernsthaft erwarten, dass wir auf jeder Maschine den Agenten in Version 10.2.0.2 installieren, damit wir ihn dann auch auf jeder Maschine separat patchen können! So zumindest lässt sich die Dokumentation zum Patch (doc/ReleaseNotes_EMGC_10.2.0.4.html) interpretieren. Sie erwähnt allerdings auch, dass oft übersehen wird, die Clone Support Files von Metalink herunterzuladen und zu installieren, nachdem man den Patch durchgeführt hat. Echt gut zu wissen – leider schreiben sie nirgends, wo man diese denn bei Metalink findet. Eine Suche auf Metalink zeitigt auch nur Erfolg, wenn man weiß, wo und wie genau man suchen muss:

Tab "Patches and Updates", hier dem Link "Advanced Search" folgen. Als "Produkt" Enterprise Manager Grid Control (emgrid) auswählen, "Patch Type" auf Any setzen, bei "Description" ist einzutragen: CLONE SUPPORT FILES FOR%. Jetzt noch die "Priority" auf Any gesetzt, und das Formular abgeschickt – und wir dürfen feststellen, dass dieser Patch nur das Klonen von Oracle 9i Datenbanken betrifft – wer solche nicht (mehr) einsetzt, kann sich also zumindest diesen Patch sparen …

Agenten neu installieren

Problem: Da ist zwar bereits ein Agent auf einer gewissen Maschine installiert – jedoch soll dieser durch einen anderen ersetzt werden.

Ursache: Oh, da käme einiges in Betracht: Eine ältere Version soll durch eine neuere ersetzt werden – aber aus irgend einem Grund kommt Patchen nicht in Betracht; eine vorige Installation ist fehlgeschlagen oder später kaputt gegangen; die vorige Installation erfolgte in ein Verzeichnis, welches nicht mit den allgemeinen "Verzeichnis-Struktur-Richtlinien" der Firma korreliert …

Lösung: KEINESFALLS einfach den neuen Agenten über (oder neben) den bestehenden installieren!!! Das geht entweder ohnehin schief (bei gleichem Verzeichnis weigert sich der Installer), oder es hagelt Alarme der Art Number of Duplicate Targets exceeded the critical threshold. Also besser wie folgt vorgehen:

1. Sicherstellen, dass alle vom betroffenen (alten) Agenten überwachten Ziele aus GridControl entfernt wurden
2. Den (alten) Agenten stoppen
3. Meldet GridControl auch nach einer akzeptablen Zeit (max. 15 Minuten) noch, der Agent sei "down" bzw. "nicht erreichbar", bietet jedoch keine Möglichkeit an, ihn zu entfernen – meldet man sich als SYSMAN an der Repository Datenbank an und setzt den Befehl exec mgmt_admin.cleanup_agent('<myserver>:<port>') ab (siehe Metalink Note 454081.1) – das ist die "harte Tour", das Teil endgültig loszuwerden.
4. Auf dem Zielhost ist sich nun als oracle anzumelden, in das Verzeichnis $AGENT_HOME/oui/bin zu wechseln, und das ./runInstaller Skript zu starten. Hiermit löschen wir nun den (alten) Agenten.
5. Jetzt können wir gefahrlos den (neuen) Agenten installieren, wie es z. B. [hier]#agent) bereits beschrieben wurde.
6. Grrr … und jetzt müssen die "neuen" Ziele wieder neu konfiguriert werden. Hoffentlich wurden zuvor Templates angelegt, die man nun einfach nur noch anwenden muss …

Alarme und Policies

Grid meldet der Listener sei "down" – lsnrctl ist anderer Meinung

Problem: Es kann passieren, dass GridControl einen Listener als "down" markiert – obwohl der betreffende laut lsnrctl status (und auch laut allen Clients, die sich einwandfrei zur Datenbank verbinden können) einwandfrei läuft. Abwarten hilft nichts, auch ein Neustart sowohl des Listeners, des Agenten und des OMS bringen keine Abhilfe.

Ursache: Die weiß wohl keiner so richtig zu benennen. Unmittelbar nach der Installation war alles in Ordnung. Der Fehler trat erst auf, nachdem OMS, Listener und/oder Agent (evtl. aufgrund des Patchens) neu gestartet wurden.

Lösung: Die gibt es möglicherweise. Bei Metalink finden sich mehrere Service Requests zu diesem Thema – allesamt ohne Lösung. Bei Google noch mehr Fragen (und Antworten) dazu. Lösungshinweise beinhalten gar das manuelle Bearbeiten von Konfigurationsdateien – ob reiner Text oder XML. Doch bevor wir uns an solchen zu schaffen machen, können wir zunächst etwas einfacheres probieren:

In GridControl wählen wir aus der Klappbox der Zielsuche den Punkt Agent, und schicken das Formular ab. Auf der nächsten Seite wählen wir den zugehörigen Agenten aus, und gelangen zu einer Liste der von ihm überwachten Ziele. Hier suchen wir den betroffenen Listener, und entfernen ihn kurzerhand. Problem weg – kein Listener mehr down.

Wem das jetzt nicht reicht (wohl jeder von uns), der fügt ihn nun wieder manuell als neues Ziel hinzu. Mit an Sicherheit grenzender Wahrscheinlichkeit listet GridControl ihn nun korrekt als "up".

PLS-00201: identifier 'MGMT_CNTR_TT.CLEAN_UP_OLD_TICKET_RECS' must be declared

Problem: Schon bald nachdem wir den Patch eingespielt haben, taucht obige Fehlermeldung im Alertlog (und folgerichtig auch in den Alerts von GridControl) auf: Ein Job ist aufgrund dessen fehlgeschlagen.

Ursache: Der Job wurde unter dem falschen Benutzer (SYS anstatt SYSMAN) angelegt. Doch selbst mit dem richtigen Besitzer fällt der Job nach wie vor – wenn auch mit anderer Fehlermeldung – auf die Nase (siehe Metalink Note 416352.1 für Details).

Lösung: O. g. Metalink-Dokument nennt eine Reihe von Bugs, die in diesem Zusammenhang bereits (für GridControl 10.2.0.3) gelistet sind. Offensichtlich wurden diese in 10.2.0.4 noch nicht behoben. Als Work-Around wird empfohlen, den Job einfach zu entfernen:

SQL> exec dbms_job.remove(<job_id>)

Logisch: Ein Job, der nicht (mehr) existiert, kann auch nicht (mehr) fehlschlagen …

Warnungen und Fehler, weil eine Standby-Datenbank "nicht geöffnet" ist

Problem: Es hagelt Warnungen und Fehler bzgl. einer Standby-Datenbank, die entweder direkt einen ORA-01219: database not open: queries allowed on fixed tables/views only Fehler erwähnen oder sich auf einen solchen zurück verfolgen lassen.

Ursache: Ein Bug im Agenten (siehe z. B. MetaLink Note 403223.1), der angeblich in Version 10.2.0.4 behoben wurde – was aber offensichtlich nicht der Fall ist.

Lösung: Gute Frage. Auf Metalink gibt es hierfür einen Patch (siehe Bug 6442193) sowie Suche nach dem Patch mit gleicher Nummer), der auf den 10.2.0.4 Agenten angewendet werden soll. Brachte zumindest hier keine Abhilfe.

Nachdem ein entsprechender Service-Request bei Metalink auch nach 2 Monaten noch keine brauchbaren Ergebnisse brachte, fand ich die Lösung "zufällig" als Nebeneffekt der Behebung eines anderen Problems: Da Grid plötzlich meinte, es könnten einige Statistiken nicht mehr erfasst werden, da die Data Guard Konfiguration fehle (komisch, dass das zwei Monate auch ohne ging?) – habe ich den Data Guard Broker konfiguriert – und plötzlich waren auch diese Fehler verschwunden! Wie das geht:

1. GridControl Webseite öffnen
2. Auf den Reiter "Ziele" klicken
3. Direkt unter der Tab-Leiste, auf "Datenbanken" klicken
4. Die betroffene Primäre Datenbank anklicken
5. Im Bereich "High Availability" auf den Link Primär klicken
6. Wenn Login-Daten erfragt werden, die nötigen Daten für einen SYSDBA Account (z. B. SYS) eingeben
7. Unter "Überblick" auf den Link Data Guard Broker verwenden klicken
8. Den dortigen Anweisungen folgen

Ein kleiner Nebeneffekt ist, dass sich ein SwitchOver bzw. FailOver nun mit nur wenigen Mausklicks auslösen lässt.

Auch wenn Metalink behauptet, dass ein weiterer Patch das Problem beheben soll (Patch #6442193 für den Agenten 10.2.0.4 – nach dessen Anwendung muss jedoch die betroffene Standby Datenbank als Grid Control Target entfernt und wieder neu hinzugefügt werden, da anders die bereits bestehenden Alerts nicht gelöscht werden), kann ich dies nicht bestätigen. Nach Anwendung des Patches (und einem Datenbank Neustart) hagelte es sogar noch mehr der schönen ORA-01219 Fehler. Damit scheint die Konfiguration des Data Guard Brokers derzeit die einzig brauchbare Lösung zu sein – auch wenn damit nach wie vor zwei Warnungen bestehen bleiben, dass die Datenbank gemounted (und nicht geöffnet) ist – und die anderen Fehlermeldungen u. U. nach einem Neustart wieder auftauchen.

Probleme mit der Open Ports Policy

Problem: Ursprünglich gab es hier Alerts für 5 Ports. Da diese zu Recht offen waren (üblicherweise sind es außer dem SSH Port eine Reihe von Oracle Ports wie Listener, Agent, etc., welche wir ja benötigen), wurden sie in die Liste auszuschließender Objekte eingetragen. Seitdem gibt es keinen Alarm mehr für weitere offene Ports – obwohl definitiv noch Ports offen sind.

Ursache: Die Voreinstellung ist hier, dass die Gesamtliste (also alle offenen Ports inklusive der Ausschlussliste) nicht mehr als 5 Einträge haben darf. Sind also bereits 5 Einträge in der Ausschlussliste, gibt es auch keinen Alarm mehr.

Lösung: Tja – da können wir die Policy auch ausschalten. Wenn wir sie jedoch benötigen, müssen wir die Einschränkung auf 5 Einträge aufheben. Das geht wie folgt:

Zuerst den Tab "Jobs" auswählen. Aus dem Drop-Down "Job erstellen" wählen wir Konfiguration der Sicherheits-Policy, und klicken auf den Button "Weiter" direkt daneben. Nun müssen wir dem Job einen (aussagekräftigen) Namen (und optional eine Beschreibung) verpassen. "Zieltyp" belassen wir auf Host, und benutzen den Button "Hinzufügen" zur Auswahl der gewünschten Ziel-Hosts.

Nun wechseln wir auf den Tab "Parameter", wählen Offene Ports aus der Klappbox "Sicherheits-Policy", und geben im Eingabefeld "Maximale Zeilenanzahl" die gewünschte Anzahl der maximal zu berichtenden offenen Ports (bzw. All für das vollständige Entfernen des Limits) an.

Weiter geht es im Tab "ID-Daten". Wer noch keine bevorzugten ID-Daten für jeden der beteiligten Hosts hinterlegt hat, markiert hier die Radio-Box "Bevorzugte ID-Daten außer Kraft setzen", und gibt eine für alle beteiligten Hosts gültige Benutzer/Passwort Kombination ein. (Hinweis: Der root Account ist OK, jedoch sollte dann nicht versucht werden, die Radio-Box "Sudo" zu markieren, um auf den Benutzer oracle (oder einen anderen Benutzer) zu wechseln. In diesem Falle schlägt der Job fehl und behauptet, Sudo sei nicht verfügbar. Ohne Sudo funktioniert es aber auch mit dem root Account.)

Wurde abschließend noch auf den Button "Weiterleiten" geklickt, und die Jobs erfolgreich ausgeführt, sollte es in Kürze wieder Alarme bzgl. offener Ports hageln.

Alert: Fehler – Missing Properties

Problem: In "Alle Ziele - Alerts" finden wir einen oder mehrere Fehler mit der Beschreibung Missing Properties: […]. Der Fehlertyp ist Erfassungsfehler.

Ursache: Die dynamic properties werden nicht korrekt berechnet (siehe Metalink Bug 5283003).

Lösung: Metalink bietet in der Note 422847.1 als Lösung an, auf dem Zielhost den Befehl

$AGENT_HOME/bin/emctl reload agent dynamicproperties <target>:<type>
$AGENT_HOME/bin/emctl clearstate agent
$AGENT_HOME/bin/emctl upload

abzusetzen (<target>: Name des betroffenen Ziels, wie aus der Spalte Ziel des Fehler-Reports ersichtlich; <type>: Zieltyp, z. B. host für einen Host, oder oracle_database für eine Oracle Datenbank). Nachdem genannte drei Befehle ausgeführt wurden, noch 5-10 Minuten warten – und dann die Liste der Alarme nochmals prüfen: Die Alarme bzgl. der Missing Properties sollten nun zurückgesetzt worden sein. Zugegeben: Bei uns klappte das auch erst beim zweiten Mal – also bei Bedarf einfach nochmal probieren.

Zahlreiche "Erfassungsfehler" mit ORA-00600

Problem: In den Ziel-Alerts finden sich eines schönen Tages gleich eine ganze Reihe von Erfassungsfehlern – alle fein mit einem ORA-00600 [17059] in den Details versehen, welcher auf der Repository-Datenbank aufgetreten ist. Als wäre das noch nicht genug, tritt dieser ORA-00600 weiterhin im Minutentakt auf, und legt dabei auch fleißig (nicht gerade kleine) Trace Dateien an.

Ursache: Die Repository-Datenbank ist wahrscheinlich Oracle 10.2.0.3 unter Windows oder Linux, und wurde von Bug 5705795 heimgesucht.

Lösung: Herzlichen Glückwunsch! Der Hauptgewinn dieser Lotterie ist ein weiteres Patch-Set … Bitte zunächst mit dem Metalink-Support (durch Erstellen eines Service-Requests) abklären, ob das auch wirklich zutreffend ist. Sodann gibt es ein passendes Patch-Set (#5705795) zum Download, welches wir zur Abwechslung einmal nicht auf Grid Control, sondern die Repository Datenbank anwenden dürfen.

Anmerkung: Trotz eingespieltem Patch-Set #5705795 kann es sein, dass das Problem weiterhin auftritt. Abhilfe schaffen sollte hier ein Upgrade der Datenbank auf Version 10.2.0.4. Ob das dann jedoch die endgültige Lösung ist (oder das Problem dennoch bestehen bleibt), muss sich erst noch zeigen …

Alerts: "Benutzer SYS angemeldet von …"

Problem: Wer eine Dataguard Umgebung hat, muss zumindest seine Standby-Datenbanken über einen Benutzer mit SYSDBA Rechten überwachen lassen – und hat Grid Control sicher auch so (Benutzer: SYS) konfiguriert. Die Folge sind dauerhaft bestehen bleibende Alerts – da sich ja der Agent nun stetig als SYS angemeldet hat. Was lässt sich da tun?

• An einem Benutzer mit SYSDBA Berechtigung führt kein Weg vorbei
• Selbst wenn man einem anderen Benutzer (außer vielleicht DBSNMP – anbieten würde sich hier SYSTEM, da man mit SYSDBA ja nicht unbedingt verschwenderisch sein möchte) SYSDBA, SELECT ANY DICTIONARY und OEM_MONITOR zugewiesen hat, erhält man bei der Einrichtung die Fehlermeldung "Benutzer system hat keine Berechtigungen zur Überwachung dieser Datenbank."
• Das Metalink-Dokument 311684.1 erwähnt, dass OEM_MONITOR via EM Database Configuration Tool – und nicht mittels via SQL^*Plus – zugewiesen werden muss. Das Befolgen dieses Ratschlages (und die Verwendung der Grid Umgebung hierfür) ändert aber auch nichts
• Klar kann man nun den Audit abschalten (womit die Alerts dann auch verschwinden), aber das ist sicher nicht der Weisheit letzter Schluss.

Ein Service Request bei Metalink ist hierfür bereits angelegt. Dort wies man mich zunächst auf die in der Datei $ORACLE_HOME/rdbms/admin/catsnmp.sql aufgeführten Berechtigungen für den DBSNMP Account hin (siehe auch Metalink Note 315340.1) – was im Grunde genommen genau auf obiges hinausläuft (zzgl. einem direkten GRANT EXECUTE ON DBMS_SERVER_ALERT, der aber am Sachverhalt nichts änderte)

Ursache: Wie ein jeder sicher bereits erwartet hat, liest der Agent einfach sämtliche Sessions (also auch seine eigenen) aus v$session. Da der Agent oft gleich mehrfach an der Datenbank angemeldet ist, kann er wohl auch nicht einfach nur seine eigene Session ausblenden (und versucht dies auch gar nicht erst).

Lösung: Von Oracle selbst ist hier offensichtlich keine Lösung zu erwarten (ich zitiere den Koordinator des zuständigen Metalink-Teams: "This is a configuration issue. no statement need to be changed in the xml/xmlp file. Just disable this policy on the databases that you would like to monitor under the SYS account." (Zu Deutsch: Dies ist eine Sache der Konfiguration, [für uns] gibt es da nichts in den XML/XMLP Dateien zu ändern. Deaktivieren Sie einfach diese Regel für die Datenbanken, die Sie mit dem SYS Account überwachen wollen"). Also müssen wir uns selbst helfen, z.B. mit folgenem Work-Arount – aber bitte bedenken, dass dieser nicht offiziell von Oracle unterstützt wird:

• auf dem betroffenen Server die Datei $AGENT_HOME/sysman/admin/metadata/instance.xmlp zum Bearbeiten öffnen
• nach "v$session" suchen - was zu der Zeile
  from v$session where type <> 'BACKGROUND' and username is not null )
  führen sollte (einige Zeilen weiter oben sehen wir das bestätigt: "Category: User Audit", also genau das, was wir korrigieren wollen)
• die schließende Klammer ")" am Ende der Zeile entfernen, und unmittelbar danach folgende Zeile einfügen:
  and not (program like 'emagent@%' and machine=(select host_name from v$instance)) )
• in Grid Control die Metrik für "Auditierte Benutzer" bearbeiten ("SYS" entfernen oder durch etwas anderes ersetzen), damit der Event zunächst aufgelöst wird
• den Agenten auf dem betroffenen Server neu starten ($AGENT_HOME/bin/emctl stop agent && $AGENT_HOME/bin/emctl start agent) die Metrik nun erneut bearbeiten, und SYS wieder aufnehmen

Diese Schritte für jeden weiteren betroffenen Server wiederholen – und die Agenten sollten sich zukünftig nicht mehr über sich selbst beschweren.