Überwachen von Oracle-Datenbanken

Letzte Aktualisierung: 21. September 2017


1. Einleitung

Check_MK bietet Ihnen umfangreiche Möglichkeiten Oracle-Datenbanken zu überwachen. So können Sie mit dem Plugin nicht nur Tablespaces oder die aktiven Sitzungen einer Datenbank abrufen, sondern zusätzlich noch viele andere Performancedaten. Eine vollständige Liste der Überwachungsmöglichkeiten können Sie in unserem Katalog der Checkplugins nachlesen. Wir erweitern dieses Plugin regelmäßig, so dass sich ein Blick in den Katalog immer wieder lohnt. Unter anderem kann Check_MK die folgenden Werte überwachen:

  • Oracle Database Instance
  • Oracle Database Processes
  • Oracle Database Recovery Area
  • Oracle tablespaces
  • Oracle tablespaces: perfomance data
  • Oracle Database Locks
  • Oracle Database Jobs
  • Oracle Database Long Active Sessions
  • Oracle RMAN Backup Status
  • Oracle ASM Disk Groups
  • Oracle Clusterware: Cluster Resources
  • Oracle Clusterware: Voting Check
  • Check Undo Retention of Oracle Instances
  • Check apply and transport lag of Oracle Data-Guard
  • Log switch activity of Oracle database
  • Number of active sessions in Oracle database

Um die Datenbanken überwachen zu können, brauchen Sie lediglich das Plugin zusätzlich zu dem Agenten auf dem Datenbankserver. Unterstützt werden dafür zur Zeit die Betriebssysteme Linux, AIX, Solaris, HP-UX und Windows. Zusätzliche Software wird weder auf der Check_MK-Instanz noch auf dem Datenbankserver für eine Überwachung benötigt.

Im Folgenden wird die Einrichtung über Linux beschrieben. Für die anderen unixoiden Betriebssysteme gilt die gleiche Beschreibung. Grundsätzliches zu der Einrichtung unter Windows finden Sie weiter unten, ebenso, wie die Einrichtung über die Agent Bakery.

2. Erste Einrichtung

Die Überwachung einer einfachen lokalen Instanz ist in nur drei Schritten konfiguriert. Es gibt dabei lediglich die folgenden Vorraussetzungen:

  • Sie haben die Berechtigung, Benutzer in der Datenbank anzulegen.
  • Sie haben Systemrechte auf dem zu überwachenden Server.

Benutzer anlegen

Die Benutzer werden für jede Datenbank einzeln angelegt. Sie müssen also vor jedem Login die jeweilige Instanz als Environment-Variable setzen, z. B. für die SID MYINST1:

root@linux# su - oracle
oracle@linux export ORACLE_SID=MYINST1

Loggen Sie sich danach in die Instanz ein, legen Sie einen Benutzer für das Monitoring an und geben Sie ihm die nachfolgenden Berechtigungen. Unser Benutzer heißt check_mk, der Name ist jedoch prinzipiell egal:

sqlplus> create user check_mk identified by myPassword;
sqlplus> grant select_catalog_role to check_mk;
sqlplus> grant create session to check_mk;
sqlplus> connect check_mk/myPassword
sqlplus> exit

Konfigurationsdatei anlegen

Danach legen Sie die Konfigurationsdatei mk_oracle.cfg unter /etc/check_mk an:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='check_mk:mypassword'

Achten Sie darauf, dass die Datei nur von root lesbar ist und niemand anderes darauf zugreifen kann:

root@linux# chmod 600 /etc/check_mk/mk_oracle.cfg

Skript in das Pluginverzeichnis schieben

Das Plugin mk_oracle bzw. mk_oracle.aix finden Sie unter share/check_mk/agents/plugins/. Falls kein direkter Zugriff auf den Monitoring Server möglich ist, können Sie die Datei alternativ auch über den Webbrowser erreichen. Sie finden das Verzeichnis hier direkt über die Adresszeile myserver/mysite/check_mk/agents/plugins/. Wählen Sie die für Ihren Datenbankserver richtige Version des Plugins aus. Das Plugin mk_oracle.ps1 für Windows-Server liegt unter myHost/mySite/check_mk/agents/windows/plugins/. Bitte beachten Sie, dass das Plugin mk_oracle.bat veraltet ist und nicht mehr benutzt werden sollte.

Legen Sie das Plugin auf dem Datenbankserver in dem Verzeichnis /usr/lib/check_mk_agent/plugins/ ab und stellen Sie sicher, dass das Plugin ausführbar ist:

root@linux# cp mk_oracle /usr/lib/check_mk_agent/plugins/
root@linux# cd /usr/lib/check_mk_agent/plugins
root@linux# ls -lA
-rw-r--r-- 1 root root 49743 Jan 25 11:29 mk_oracle
root@linux# chmod +x mk_oracle
root@linux#  ls -lA
-rwxr-xr-x 1 root root 49743 Jan 25 11:29 mk_oracle

In älteren Versionen des Check_MK-Agenten kann sich das Pluginverzeichnis auch an einem anderen Ort befinden. Falls Sie sich unsicher sind, ob Sie davon betroffen sind, können Sie das Verzeichnis folgendermaßen identifizieren:

root@linux# grep MK_LIBDIR= /usr/bin/check_mk_agent
export MK_LIBDIR="/usr/lib/check_mk_agent"

Haben Sie diese Schritte erledigt, ist die Installation bereits komplett und Sie können in Check_MK eine Serviceerkennung durchführen und die neu erkannten Services aktivieren. Der Screenshot zeigt in diesem Fall nur eine Auswahl der Services:

3. Erweiterte Konfiguration

Je nach Anwendungsszenario stehen Ihnen einige weitere Möglichkeiten zur Verfügung um die Überwachung von Oracle-Datenbanken zu konfigurieren. Alle diese Optionen stehen Ihnen auch in der Agent Bakery zur Verfügung. Für die Konfiguration des Benutzers gibt es die folgenden Optionen:

Parameter Beschreibung
DBUSER Die Zugangsdaten für die Datenbankinstanz, wenn für alle die gleichen Logindaten konfiguriert wurden, bzw. als Standard für nicht explizit definierte SIDs.
DBUSER_MYINST1 Zugangsdaten für die Datenbankinstanz MYINST1. Die Logindaten werden nur für die angegebene SID benutzt.
ASMUSER Die Zugangsdaten für das Automatic Storage Management (ASM).

So können Sie genau bestimmen, ob Sie auf jeder Datenbank die gleichen Benutzerdaten anlegen oder für einzelne separate Logins vergeben. Für die ASM kann nur ein Benutzer angegeben werden. Rolle, Host und Port sind optional und können ausgelassen werden. Eine mk_oracle.cfg kann dann so aussehen:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# DBUSER='myUser:mypassword:role:host:port'
DBUSER='check_mk:myPassword'
DBUSER_MYINST1='this_user:this_password:sysdba:localhost:1521'
DBUSER_MYINST2='that_user:that_password::localhost'

Zusätzlich sind die folgenden Optionen verfügbar, mit deren Hilfe Sie unter anderem bestimmen, welche Daten in welcher Reihenfolge geholt werden sollen:

Parameter Beschreibung
ONLY_SIDS Überwachung nur für die hier festgelegten SIDs. Alle anderen Instanzen werden ignoriert.
EXCLUDE_MYINST1 Die Instanz MYINST1 wird bei der Überwachung ganz oder teilweise nicht berücksichtigt. Dies kann sinnvoll sein, wenn nur einige wenige SIDs ausgeschlossen werden sollen und die Zahl der zu überwachenden Instanzen größer ist oder einzelne Sektionen in bestimmten SIDs nicht abgefragt werden sollen. Mögliche Werte sind ALL oder Namen von Sektionen.
SYNC_SECTIONS Sektionen sind alle SQL-Statements bzw. Funktionen in dem Plugin. Dieser Parameter bestimmt, welche Sektionen synchron abgefragt werden sollen. Wenn der Parameter nicht genutzt wird, werden die Standardwerte genommen, wie in dem unten stehenden Konfigurationsbeispiel zu sehen. Wichtig: Wenn die Sektionen manuell gesetzt werden, müssen alle Sektionen in SYNC_SECTIONS oder ASYNC_SECTIONS vorkommen. Anderfalls werden diese nicht abgefragt!
ASYNC_SECTIONS Sektionen, welche asynchron abgefragt werden sollen, werden hier bestimmt. Der Wert wird dann eine bestimmte Zeit vorgehalten. Siehe CACHE_MAXAGE.
SYNC_ASM_SECTIONS Siehe SYNC_SECTIONS; Gilt für Sektionen der ASM.
ASYNC_ASM_SECTIONS Siehe ASYNC_SECTIONS; Gilt für Sektionen der ASM.
CACHE_MAXAGE Überschreibt den Standardwert für die Vorhaltezeit der asynchron abgerufenen Sektionen.

Hier ein Beispiel, wie das in der mk_oracle.cfg aussieht:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# Variable='Wert'

# Nur die zwei gegebenen Sektionen in dem Schema MYINST1 ausschließen:
EXCLUDE_MYINST1='longactivesessions logswitches'

# Alle Sektionen in der Instanz MYINST2 ausschließen:
EXCLUDE_MYINST2='ALL'

# Alle Sektionen, welche hier nicht aufgeführt werden, werden nicht abgeholt:
SYNC_SECTIONS='instance performance processes sessions undostat'
ASYNC_SECTIONS='jobs resumable rman tablespaces ts_quotas'

4. Entfernte Datenbanken

Mit dem mk_oracle Plugin können Sie unter Linux auch auf Datenbanken zugreifen, welche auf einem anderen Host laufen. Diese können dann sogar einem anderen Host in Check_MK zugeordnet werden (Piggyback). Damit der entfernte Zugriff funktioniert, muss entweder eine lokale Oracle-Installation vorhanden oder es müssen die folgenden Voraussetzungen erfüllt sein:

  • Die Linux AIO access library ist installiert. Unter RHEL/CentOS heißt das Paket libaio.
  • Der Instant Client for Oracle Database ist installiert.
  • SQLPlus ist in der Installation schon vorhanden oder muss ggf. als Erweiterungspaket zu dem Client installiert werden.

Das Plugin wird ebenso wie oben beschrieben auf dem Host installiert. Damit sich das Plugin nun mit einer entfernten Datenbank verbinden kann, müssen in der Konfigurationsdatei die Zugangsdaten hinterlegt werden. Diese können Sie mit den anderen Konfigurationsmöglichkeiten kombinieren, so dass Sie problemslos gleichzeitig lokale und entfernte Datenbanken abfragen können. Die Erweiterung der Konfiguration kann z. B. so aussehen:

/etc/check_mk/mk_oracle.cfg
# Syntax:
# Variable='Wert'
# REMOTE_INSTANCE_[ID]='myUser:myPassword:role:host:port:piggybackhost:SID:version'

REMOTE_INSTANCE_1='check_mk:mypassword::myRemoteHost:1521:myOracleHost:MYINST3:11.2'
REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'

REMOTE_INSTANCE_this='check_mk:mypassword::myRemoteHost:1521::MYINST1:11.2'
REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'

In dem Beispiel wurden Abfragen für zwei entfernte Instanzen konfiguriert. Die Instanz MYINST3 wird dabei in Check_MK dem Host myOracleHost über das Huckepackverfahren zugeordnet. Damit das funktioniert, muss der Host in Check_MK genauso heißen, wie in der Konfiguration angegeben. Denken Sie hier auch an Groß-/Kleinschreibung. Durch Auslassung dieses Konfigurationsteils rufen Sie die Instanz zwar von einem entfernten Host ab, ordnen die Daten aber dem Host zu, auf dem das Plugin läuft. Das kann von Vorteil sein, wenn Sie zwar Zugriff auf die Daten haben, aber der Host aufgrund mangelnder allgemeiner Zugriffsmöglichkeiten gar nicht in Check_MK angelegt ist.

Wie Sie feststellen können, ist die Konfiguration ansonsten sehr ähnlich zu einer normalen Abfrage. Sie geben Benutzername und Passwort an, konfigurieren bei Bedarf Port und Rolle des Benutzers und setzen den Hostnamen, auf dem die Datenbank läuft. Zusätzlich müssen Sie hier nur noch die SID der Instanz angeben und die Version der Datenbank, auf dem sich diese Instanz befindet.

Die Information REMOTE_ORACLE_HOME wird dann angegeben, wenn der abrufende Server keine lokale Oracle-Installation hat und nur über den Client verfügt. Bei diesem gibt es leider keine andere Möglichkeit an diesen Pfad zu kommen. In dem Beispiel wurde der reguläre Pfad für den Client angegeben.

Wichtig: Die SIDs dürfen nicht mehrmals vorkommen, wenn Sie gleichzeitig lokale und entfernte Instanzen abrufen und dem gleichen Host zuordnen!

5. Besonderheiten bei Cluster-Instanzen

5.1. Standby-Datenbanken ohne Data Guard

Um Standby-Instanzen zu überwachen, welche nicht über Active Data Guard verfügen, benötigt der Benutzer, mit welchem die Überwachungsdaten geholt werden, die SYSDBA-Rolle. Durch diese Berechtigung ist der Benutzer auch dann in der Lage zumindest einen Teil der Daten zu holen, wenn die primäre Instanz ausfällt und auf dem Standby-Server die Datenbank noch nicht von MOUNTED auf OPEN umgestellt wurde. Sie können die Berechtigung u. a. bei der Erstellung des Benutzers wie oben beschrieben durch den folgenden, zusätzlichen Befehl zuweisen:

sqlplus> grant sysdba to check_mk;

Damit die Daten im Fehlerfall von dem Standby-Server abgefragt werden können, wird der Benutzer auf der primären Instanz erstellt und die Passwortdatei dann auf den Standby-Server kopiert. Danach setzen Sie in der Konfigurationsdatei mk_oracle.cfg die Rolle des Benutzers ebenfalls auf SYSDBA:

/etc/check_mk/mk_oracle.cfg
DBUSER='check_mk:myPassword:sysdba:localhost:1521'

Hostnamen und Port können Sie wie immer weglassen, wenn es sich um eine lokale Instanz mit dem Standard-Port handelt. Beachten Sie, dass das Plugin mit der Konfigurationsdatei auch auf dem Standby-Server konfiguriert werden muss, damit die Daten gegebenenfalls von dort geholt werden können.

Die folgenden Services benötigen eine Konfiguration als Clustered Services:

  • ORA .* RMAN Backup
  • ORA .* Job
  • ORA .* Tablespace

Wichtig: Die SYSDBA-Rolle ist mit einem root-Zugriff zu vergleichen. Benutzen Sie daher für eine solche Konfiguration ein ausreichend gutes Passwort!

5.2. Real Application Cluster (RAC)

In einem RAC reicht es den Benutzer nur einmal anzulegen, da dieser in der gemeinsamen Datenbank abgelegt wird. Das Plugin mit seiner Konfigurationsdatei muss allerdings auf jedem Knoten installiert werden.

Für das Monitoring sollten Sie nicht die SCAN Listener als Hosts in Check_MK, sondern die Knoten selbst benutzen. Nur dadurch ist gewährleistet, dass der Zugriff über das Plugin funktioniert.

Auch hier gibt es Services, welche eine Konfiguration als Clustered Services benötigen:

  • ASM Diskgroup .*
  • ORA .* Recovery Area
  • ORA .* RMAN Backup
  • ORA .* Job
  • ORA .* Tablespace

6. Verwendung der Oracle Wallet

Bisher wurden die Benutzerdaten immer in der Konfigurationsdatei zu dem Plugin abgelegt. Das hat nicht zuletzt den Nachteil, dass die Daten unverschlüsselt sowohl in Check_MK als auch auf dem Datenbankserver abgelegt werden. Selbst wenn Sie die Rechte der Konfigurationsdatei auf dem Datenbankserver entsprechend anpassen, haben die Zugangsdaten dennoch den Server verlassen und befinden sich auf dem Check_MK-Server.

Um dieses Problem anzugehen, bietet Oracle die Wallet an, in der die Zugangsdaten verschlüsselt abgelegt werden können. Check_MK kann diese Wallet nutzen, so dass die Zugangsdaten nicht mehr in der Konfigurationsdatei bekannt gemacht werden und auch generell nur dem Datenbankadministrator bekannt sein müssen. Dazu legen Sie oder der erwähnte Datenbankadministrator zuerst eine Wallet auf dem Datenbankserver an:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -create

Auf diese Datei wird das Plugin später immer dann zugreifen, wenn eine Verbindung zu einer Instanz hergestellt werden soll. Damit die nötigen Benutzerdaten auch gefunden werden, müssen Sie einmalig in die Wallet eingetragen werden. In dem folgenden Beispiel fügen Sie einen Benutzer für die Instanz MYINST1 hinzu:

root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 check_mk myPassword

Anschließend wird die Datei sqlnet.ora angelegt. Achten Sie darauf, dass der Parameter SQLNET.WALLET_OVERRIDE auf TRUE gesetzt ist:

/etc/check_mk/sqlnet.ora
LOG_DIRECTORY_CLIENT = /var/log/check_mk/oracle_client
DIAG_ADR_ENABLED = OFF

SQLNET.WALLET_OVERRIDE = TRUE
WALLET_LOCATION =
 (SOURCE=
   (METHOD = FILE)
   (METHOD_DATA = (DIRECTORY=/etc/check_mk/oracle_wallet))
 )

Damit die Verbindungen auch aufgelöst werden können, werden die SIDs als Alias in der tnsnames.ora angelegt. Beispiele zu einer Konfiguration finden Sie in Check_MK und in ihrer Oracle-Installation. Die Konfiguration kann z. B. so aussehen:

/etc/check_mk/tnsnames.ora
MYINST1
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = MYINST1)
    )
  )

Sie müssen nun in der mk_oracle.cfg keine Zugangsdaten mehr hinterlegen und geben lediglich noch einen führenden Schrägstrich und eventuell die Benutzerrolle an:

/etc/check_mk/mk_oracle.cfg
DBUSER='/::::'
ASMUSER='/::SYSASM::

Die Zugangsdaten des Monitoringbenutzers werden nun komplett vom Datenbankserver und nicht mehr von dem Monitoringserver verwaltet. Der Wallet können Sie später auch weitere Zugangsdaten hinzufügen.

7. Konfiguration über die Agent Bakery

7.1. Erste Einrichtung

Die Einrichtung wird unter Linux, AIX und Solaris mit der Agent Bakery sehr vereinfacht, da Syntaxfehler in den Konfigurationsdateien vermieden werden und Anpassungen an sich verändernde Umgebungen einfach bewerkstelligt werden können. Der wesentliche Unterschied zu einer manuellen Installation ist, dass Sie nur noch dann auf dem Oracle-Host auf der Kommandozeile arbeiten müssen, wenn Sie spezielle Oracle-spezifische Konfigurationen vorzunehmen möchten. Für die Überwachung von Oracle unter Windows gibt es im Moment noch keine Konfigurationsmöglichkeit in der Bakery.

Für die erste Einrichtung reicht es, wenn Sie den Datenbankbenutzer auf dem Oracle-Host und eine entsprechende Regel in der Bakery anlegen. Sie finden den Regelsatz unter WATO ➳ Monitoring Agents ➳ Rules. In dem Suchfeld können Sie dann auch nach oracle suchen:

Haben Sie für alle Instanzen denselben Benutzer angelegt, können Sie die Login Defaults nutzen. Andernfalls nutzen Sie die Option Login for selected databases und geben zusätzlich zu den Logindaten noch die SID der Instanz an:

Bei der Authentication Method haben Sie die Wahl zwischen der klassischen Eingabe von Benutzer/Passwort und der Oracle Wallet. Bei letzterer Variante müssen Sie nichts weiter konfigurieren, da Sie das dann bereits alles in der Wallet hinterlegt haben.

Die anderen Felder sind für den Login optional. Hier können Sie die Rolle als sysdba einstellen, einen spezifischen Hostnamen vergeben und den Port definieren.

Grundsätzlich ist die Eingabemaske für Logins in dieser Regel immer gleich oder zumindest sehr ähnlich aufgebaut, so dass Sie sich das Eingabeschema nur einmal merken müssen.

Ist die Regel abgespeichert und der Agente auf dem Oracle-Server aktualisiert, ist die anfangs beschriebene erste Einrichtung bereits erledigt.

7.2. Erweiterte Optionen

Sie haben auch in der Agent Bakery die Möglichkeit, das Monitoring Ihrer Oracle-Instanzen feingliedrig anzupassen. Die Optionen aus der erweiterten Konfiguration stehen Ihnen auch hier zur Verfügung. Beachten Sie, dass die zu holenden Sektionen über die Option Sections - data to collect einmal grundsätzlich bestimmt werden. Wird diese Option nicht aktiviert, so verwendet Check_MK den Standard vom Plugin.

Danach können Sie einzelne Sektionen für bestimmte Instanzen über die Option Exclude some sections on certain instances ausschließen.

Auch die Überwachung entfernter Instanzen kann man mit der Agent Bakery konfigurieren. Noch einmal das erste Beispiel von oben: Hier haben Sie als ID für den Parameter die 1 verwendet. Um das hier abbilden zu können, muss die Unique ID entsprechend angepasst werden:

Jede entfernte Instanz muss eine eindeutige ID bekommen. Sie könnnen auch den Host angeben, auf dem in Check_MK die Daten angezeigt werden sollen. In diesem Fall wird die Unique ID auf Use monitoring host name umgestellt und der Hostname in der Option Monitoring host this database should be mapped to angegeben. Andernfalls kann dieses Feld frei bleiben.

8. Konfiguration in Windows

Eine genaue Beschreibung folgt demnächst. Aus dem Grund erst einmal nur grundlegende Informationen: Das Plugin und die Konfigurationsdatei werden unter dem Pfad abgelegt, wo Sie auch den Agenten installiert haben. In dem Beispiel ist das der Standardpfad. Informationen zu dem Inhalt der Konfigurationsdatei finden Sie in dem Skript selbst.

Datei Windows Pfad
mk_oracle.ps1 %programfiles(x86)%\check_mk\plugins\
mk_oracle.cfg.ps1 %programfiles(x86)%\check_mk\

Wichtig: Für Windows besteht derzeit noch nicht die Möglichkeit, die Konfiguration über die Agent Bakery vorzunehmen.

9. Diagnosemöglichkeiten

Um zu testen, ob die Konfiguration auf dem Oracle-Host korrekt ist, können Sie das Plugin mit der Option -t aufrufen. Dafür wird vorher der Pfad zu den Konfigurationsdateien der Konsolensitzung bekannt gemacht:

root@linux# export MK_CONFDIR="/etc/check_mk/"
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -t

Beachten Sie, dass der Pfad zu dem Plugin unter Umständen anders sein kann. Wie Sie den Pfad für die Plugins herausfinden, wird weiter oben bei der Installation des Plugins beschrieben. Die Ausgabe wird bei einer erfolgreichen Verbindung etwa wie folgt aussehen:

<<<oracle_instance>>>
<<<oracle_sessions>>>
<<<oracle_logswitches>>>
<<<oracle_undostat>>>
<<<oracle_recovery_area>>>
<<<oracle_processes>>>
<<<oracle_recovery_status>>>
<<<oracle_longactivesessions>>>
<<<oracle_dataguard_stats>>>
<<<oracle_performance>>>
<<<oracle_tablespaces>>>
<<<oracle_rman>>>
<<<oracle_jobs>>>
<<<oracle_ts_quotas>>>
<<<oracle_resumable>>>
<<<oracle_locks>>>
<<<oracle_instance>>>
<<<oracle_asm_diskgroup>>>
-----------------------------------------------
Logincheck to Instance: +ASM  Version: 12.1
Login ok User: SYS on ora12c.local
SYNC_SECTIONS= instance
ASYNC_SECTIONS= asm_diskgroup
-----------------------------------------------
Logincheck to Instance: MYINST1  Version: 12.1
Login ok User: CHECK_MK on ora12c.local
SYNC_SECTIONS= instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance
ASYNC_SECTIONS= tablespaces rman jobs ts_quotas resumable locks

Ist die Verbindung nicht zustande gekommen, werden Sie in der Ausgabe über die Ursache informiert. Ein Fehlerhafter Login kann z. B. an einer falschen Syntax in der mk_oracle.cfg liegen. Dort ist besonders auf die Doppelpunkte zwischen den einzelnen Parametern zu achten.

Den Login können Sie auch prüfen, indem Sie sich mit dem konfigurierten Benutzer auf dem Host in Oracle anmelden. Falls das erfolgreich ist, prüfen Sie auch, ob die entsprechenden Berechtigungen gesetzt sind. Beachten Sie, dass der Benutzer in der SQL-Abfrage großgeschrieben ist:

root@linux# export ORACLE_SID=MYINST1
root@linux# sqlplus check_mk
sqlplus> select * from user_role_privs where username='CHECK_MK'

USERNAME                       GRANTED_ROLE                   ADM DEF OS_
------------------------------ ------------------------------ --- --- ---
CHECK_MK                       SELECT_CATALOG_ROLE            NO  YES NO

sqlplus select * from user_sys_privs where username='CHECK_MK'

USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
CHECK_MK                       CREATE SESSION                           NO

Generell ist es für das Debugging sehr nützlich, wenn Sie zuerst mit der einfachsten möglichen Konfiguration für das Oracle-Monitoring beginnen und die Komplexität schrittweise erhöhen. So können Sie schnell herausfinden, bis wann es funktioniert und bei welcher Änderung die Einrichtung fehlschlägt. Nutzen Sie dafür auch intensiv die Konfigurationsbeispiele. Die Pfade finden Sie nachfolgend im nächsten Kapitel.

10. Dateien und Verzeichnisse

10.1. Auf dem Oracle-Host

Pfad Bedeutung
/usr/bin/check_mk_agent Der Agent, welcher alle Daten zu dem Host sammelt.
/usr/lib/check_mk/plugins/ Das übliche Verzeichnis, wo die Plugins abgelegt werden.
/etc/check_mk/oracle.cfg Die Konfigurationsdatei für das Plugin.
/etc/check_mk/sqlnet.ora Die Konfigurationsdatei, welche für die Oracle Wallet benötigt wird.
tnsnames.ora Die Konfigurationsdatei, welche einen Alias für ein Schema bestimmt. Beispieldateien liegen auch in der Oracle-Installation, aber da sich der Pfad je nach Installation unterscheidet, kann er nicht pauschal angegeben werden.

10.2. Auf dem Check_MK Server

Pfad Bedeutung
share/check_mk/agents/plugins/cfg_examples/ Hier befinden sich Beispiele zu den Konfigurationsdateien, welche auf dem Oracle-Host benötigt werden.
share/check_mk/agents/plugins/mk_oracle Das Plugin, welches auf dem Oracle-Host die Daten holt.
share/check_mk/agents/plugins/mk_oracle_asm Über dieses Plugin kann die ASM-Instanz überwacht werden.
share/check_mk/agents/plugins/mk_oracle_crs Dieses Plugin liefert Daten zu einem Oracle Cluster Manager.