Die Überwachung der Verfügbarkeit einer Oracle Datenbank ist eine essentielle Aufgabe des IT-Betriebs. Fällt eine Oracle Instanz aufgrund einer Störung aus, so sollte der DBA umgehend Benachrichtigt werden, um das Problem schnell beheben zu können und die ungeplante Ausfallzeit zu minimieren. Am Markt sind eine Vielzahl von Monitoring-Lösungen für Oracle Datenbanken in verschiedensten Ausprägungen verfügbar. Neben dem Enterprise Manager (Coud Control) von Oracle und diverser Nagios-Derrivate, gibt es eine Vielzahl Drittanbieter-Überwachungstools, die weit mehr als nur die Verfügbarkeit einer Datenbank überwachen.
In diesem Beitrag möchte ich eine von mir entwickelte, einfache und scriptbasierte Lösung vorstellen, die ein DBA einsetzen kann, wenn er keine der oben genannten Monitoring-Tools einsetzen möchte oder kann. Das Script läuft auf einem Linux-System und überwacht den Status einer Oracle Instanz, welche sich auf dem gleichen System oder auf einem entfernten Server befindet. Am Ende dieses Artikels biete sich das Script, welches in zwei Versionen zur Verfügung steht, über entsprechende Download-Links herunterladen. Es steht jedem frei das Script zu erweitern und nach seinen Bedürfnissen anzupassen.
Grundlegende Funktionsweise
Das Programm ist eine Art Watchdog für Oracle Instanzen. Das Montoring-Script wird cronjob-gesteuert alle 5 Minuten ausgeführt und versucht mit SQL*Plus eine Client-Verbindung mit der zu überwachenden Datenbankinstanz aufzubauen. Schlägt die Verbindung fehl, so wird der DBA über die Nichtverfügbarkeit der Instanz per Mail informiert. „Nicht verfügbar“ defeniere ich hierbei als nicht verfügbar aus Sicht einer Anwendung oder eines Anwendungsbenutzers. Genau genommen wird mit jeder Prüfung die Frage beantwortet, ob sich ein normaler Benutzer erfolgreich an eine Datenbankinstanz anmelden kann.
Monitoring-User
Wie bereits erwähnt, wird die Verfügbarkeit geprüft, indem eine Client-Verbindung mit der Datenbankinstanz hergestellt wird. Der dafür verwendete Datenbankuser (hier instance_monitor) muss zu diesem Zweck in der Datenbank angelegt werden, erhält aber nur die Rechte, die für eine Anmeldung erforderlich sind. Auf die Nutzung eines Datenbankbenutzers, der das SYSDBA-Privileg besitzt, habe ich bewusst verzichtet, um die Prüfung so nah wie möglich an die Bedingungen eines wenig privilegierten Anwendungsusers heranzukommen. Denn ein SYSDBA-User kann sich noch an eine Instanz anmelden, wenn es für einen User ohne SYSDBA-Privileg nicht mehr möglich ist. Die ist z.B. der Fall wenn ein Archiver Stuck auftritt oder die Datenbankinstanz sich im Status Mount oder Nomount befindet.
Anlegen des Monitoring-Users:
SQL> create user instance_monitor; SQL> grant create session to instance_monitor;
SQL*Net-Prüfung (Listener Awareness)
Da Datenbankanwendungen in der Regel nicht auf demselben Server laufen wie die Datenbank, nutzen sie SQL*Net zur Kommunikation mit der Datenbank. Sprich, die Verbindung läuft über den Oracle Listener. Aus diesem Grund wird die Prüf-Verbindung ebenfalls über den Listener ausgebaut, selbst wenn das Monitor-Script auf dem gleichen Server wie die Datenbankinstanz ausgeführt werden sollte. Ein Ausfall des Listeners bedeutet, zumindest aus Sicht einer Anwendung, eine Nichtverfügbarkeit der Instanz.
Häufige Gründe für eine erfolglose Verbindung
Wenn eine Client-Verbindung fehl schlägt, kann es unterschiedliche Gründe dafür geben. Nicht immer ist die Fehlermeldung sprechend, die Oracle ausgibt. Einen Überblick über mögliche Fehlermeldungen inklusive Erläuterung der wahrscheinlichen Ursache, findet sich in u.a. Tabelle. Die Information über die wahrscheinliche Ursache kann bei der Fehleranalyse sehr hilfreich sein und ist daher auch Bestandteil der Benachrichtigungsmail.
Error #MessageWahrscheinline Ursache
| ORA-12541 | TNS:no listener | Unter der angegenenen Adresse ist kein Listener erreichbar. Vermutlich ist der Listener oder der Host unten oder es gibt Störungen im Netzwerk. |
| ORA-12514 | TNS:listener does not currently know of service requested in connect descriptor | Die Datenbankinstanz ist vermutlich nicht gestartet und folglich nicht beim Listener registriert. Falls die Instanz nicht absichtlich heruntergefahren wurde, ist die Instanz vermutlich aufgrund eines Fehlers unten. |
| ORA-12526 | TNS:listener: all appropriate instances are in restricted mode | Die Datenbankinstanz befindet sich im RESTRICTED Mode. Es sind nur Verbindungen von Benutzern mit dem Restricted Sessions Privileg möglich. |
| ORA-12528 | TNS:listener: all appropriate instances are blocking new connections | Die Datenbankinstanz befindet sich im NOMOUNT Status. Falls die Instanz nicht absichtlich in diesen Status versetzt wurde, wurde die Datenbank vermutlich wegen eines Fehlers nicht gemounted. |
| ORA-12516 | TNS:listener could not find available handler with matching protocol stack | Wahrscheinlich ist die eingestellte maximale Anzahl der Prozesse innerhalb der Instanz erreicht. Entweder die Anzahl der Sessions ist aufgrund einer erhöhten Last angestiegen oder es gibt einen Fehler in der Anwendung. |
| ORA-01033 | ORACLE initialization or shutdown in progress | Die Datenbankinstanz befindet sich im NOMOUNT oder MOUNT Status. Falls die Instanz nicht absichtlich in diese Status versetzt wurde, wurde die Datenbank vermutlich wegen eines Fehlers nicht gemounted und geöffnet. |
| ORA-01034 | ORACLE not available | Die Datenbankinstanz ist nicht gestartet. Falls die Instanz nicht absichtlich heruntergefahren wurde, ist die Instanz vermutlich wegen eines Fehlers unten. |
| ORA-28040 | No matching authentication protocol | Das vom Client genutzte Protokoll wird von der Datenbank nicht unterstützt. Vermutlich ist der genutzte Client für die eingesetzte Datenbankversion veraltet. |
| ORA-00257 | Archiver error. Connect internal only, until freed. | Die Datenbank ist blockiert, da keine Archivelogs mehr geschrieben werden können (Archiver Stuck). Wahrscheinlich ist das Filesystem oder die ASM Disk Group, in dem die Archivelogs geschrieben werden, voll oder die eingestellte maximale Größe der Flash Recovery Area ist erreicht. |
Mail Benachrichtigung
Der DBA wird vom Script per Mail informiert, sobald keine erfolgreiche Anmeldung an die Datenbankinstanz möglich ist. Eine weitere Mail wird versendet, sobald eine fehlerfreie Verbindung an die Instanz wieder möglich ist (Gut-Meldung).
Voraussetzung für das Versenden einer Mail von einem Linux-System aus, ist die Einrichtung eines Mail Transfer Agents (MTA), damit die Mail über einen SMTP-Server zum Empfänger gelangt. Gebräuchlich ist hier Sendmail oder Postfix. Die Einrichtung und Installation eines MTA wird in diesem Artikel nicht weiter behandelt. Erwähnenswert ist jedoch, dass Postfix einfacher zu konfigurieren und meist auf einem Red Hat Linux oder Oracle Linux bereits vorinstalliert ist.
Für den Versand der Mails wird außerdem ein Linux Mail-Client benötigt. Ich stelle zwei Versionen meines Scriptes bereit, die unterschiedliche Mail-Clients verwenden. Das erste Script nutzt Sendmail als Mailclient, versendet HTML-formatierte Mails und unterstützt deutsche Umlaute. Das zweite Script nutzt Mailx als Mail-Client, versendet reine Textmails und unterstützt keine deutschen Umlaute. Der favorisierte Mail-Client muss auf dem System vorhanden sein, um Mails versenden zu können. Soll ein anderer Mail-Client genutzt werden, so muss man die entsprechenden Zeilen im Script anpassen.
Beispiel Mail Notification Instance Warnung
Betreff: WARNUNG - Instance Status ORCL @dbhost1
Die Datenbankinstanz ORCL ist nicht verfügbar!
Es sind keine Verbindungen mit der auf dem Server dbhost1 befindlichen Datenbankinstanz ORCL möglich (Produktion) !
ORA-12514: TNS:listener does not currently know of service requested in connect
Die Datenbankinstanz ist vermutlich nicht gestartet und folglich nicht beim Listener registriert.
Falls die Instanz nicht absichtlich heruntergefahren wurde, ist die Instanz vermutlich aufgrund eines Fehlers unten.
Beispiel Mail Notification Instance OK
Betreff: OK - Instance Status ORCL @dbhost1
Die Datenbankinstanz ORCL ist wieder verfügbar!
Es sind wieder Verbindungen mit der auf dem Server dbhost1 befindlichen Datenbankinstanz ORCL möglich (Produktion)!
Montoring-Script
Aufgrund der Größe des Scripts zeige ich hier nur den Beginn des Scriptes mit den Variablen, die zu konfigurieren sind. Das komplette Script instance_monitor.sh kann unter u.a. Links heruntergeladen werden. Das Script sowie die Parameterdatei sollten ein eigens dafür angelegtes Arbeitsverzeichnis kopiert werden (z.B. /home/oracle/scripts/instance_monitor).
#!/bin/bash # +-----------------------------------------------------------------------------------------+ # | Name: instance_monitor.sh | # | Autor: Frank Gerasch | # | Datum: 04.05.2017 | # | Typ: Shell-Script (Bash) | # | Funktion: Ueberwachung von Oracle Instanzen | # | Usage: instance_monitor.sh <ORACLE_SID> | # | Voraussetzung: 1. Linux (getested Red Hat ab Version 5) | # | 2. Mail Transfer Agent (MTA) fuer den Versand von Mails eingerichtet | # | 3. Mail-Client (mailx oder sendmail) installiert | # | 4. Parameterfile instance_monitor_<ORACLE_SID>.par muss vorhanden sein | # | 5. Datenbankbenutzer instance_monitor mit create session privileg | # | wurde erstellt. Der Benutzer darf kein SYSDBA-Privileg besitzen | # +-----------------------------------------------------------------------------------------+ # KONFIGURATION PFADE und MAILING #****************************************************** # Path Instance Monitor Home export WORKDIR=/home/oracle/scripts/instance_monitor # <- Arbeitsverzeichnis # Path Client Oracle Home export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1 # Mailing export SENDER_ADRESS=instance_check@example.de # <- Mail-Absender export RECIPIENT=dba@example.de # <- Mail-Empfaenger fuer die OK-Mails eport REPLYTO='dba@example.de (DBA Support)' # <- Reply Adresse ...
Download instance_monitor.sh – Version A ( Mailclient=mailx, Format=Text )
Download instance_monitor.sh – Version B ( Mailclient=sendmail, Format=HTML )
Instanz Parameterfile
Für jede zu prüfende Instanz muss eine Parameterdatei angelegt und konfiguriert werden, die Verbindungsdaten und weitere Informationen über die Instanz enthält, welche vom Monitoring-Script genutzt werden.
Beispiel Parameterdatei:
#!/bin/bash # +----------------------------------------------------------------------------------------------------+ # | Name: instance_monitor_orcl.par | # | Autor: Frank Gerasch | # | Typ: Parameterfile fuer Instance Monitor | # | Funktion: Setzen von Instanzspezifischen Variablen fuer die zu pruefende Instanz | # +----------------------------------------------------------------------------------------------------+ export ORACLE_SID=orcl # <- Hier ORACLE_SID der zu pruefenden Instanz eintragen (Instance Name) export SERVICE_NAME=orcl # <- Hier Service namen der zu pruefenden Instance eintragen export LISTENER_PORT=1521 # <- Hier Listener Port der Zieldatenbankinstanz eintragen export TARGET_HOST=dbhost1 # <- Hier Name des Hosts, auf dem die Datenbankinstanz laeuft, eintragen export OPERATING_ROLE=Test # <- Hier Betriebsrolle der Datenbank eintragen (z.B. Produkion|Test|Entwicklung ) export DB_USER=instance_monitor # <- Hier Datenbankbenutzer fuer Verbindungstest eintragen (Non-SYSDBA) export DB_USER_PASSWORD=verysafepassword # <- Hier Passwort fuer Datenbankbenutzer eintragen # (bei Wallet Connect obsolet) # EZCONNECT export CONNECT_STRING="$DB_USER/$DB_USER_PASSWORD@//$TARGET_HOST:$LISTENER_PORT/$SERVICE_NAME" # TNSNAMES (Alternativ) ###export CONNECT_STRING="$DB_USER/$DB_USER_PASSWORD@<TNS_ALIAS>" # ORACLE WALLET CONNECT (Alternativ, Enterprise Edition) ###export CONNECT_STRING="/@<DB_ALIAS>"
Das Passwort für den Datenbankbenutzer, die für die Verbindungsprüfung genutzt wird (hier instance_monitor), muss in die Parameterdatei in Klartext eingetragen werden, insofern EZCONNECT oder TNSNAMES als Verbindungsmethode genutzt werden soll. Zwar hat der Benutzer nur sehr eingeschränkte Rechte in der Datenbank (create session), in einigen Umgebungen ist dies aber aus Sicherheitsaspekten unerwünscht und deshalb nicht gestattet. In diesem Fall empfehle ich die Nutzung eines clientseitigen Oracle Wallets, bei dem das Passwort verschlüsselt in einem PKCS#12 Container abgelegt wird. Oracle Wallet ist Bestandteil des Secure External Password Store Features.
White Paper Oracle Wallet (Secure External Password Store):
http://www.oracle.com/technetwork/database/security/twp-db-security-secure-ext-pwd-stor-133399.pdf
Die Parameterdatei kann durch das Kopieren der Vorlage erzeugt werden, die unter dem u.a. Link heruntergeladen werden kann. Im Anschluss müssen die Variablen für den Verbindungsaufbau zur Instanz in einem Texteditor konfiguriert werden.
Download instance_monitor_oracle_sid.par (Vorlage)
Beispiel Erzeugung einer Vorlage für die zu prüfende Instanz ERPDB:
cp instance_monitor_oracle_sid.par instance_monitor_erpdb.par
Cronjob Scheduling
Über einen Cronjob des aufrufenden Client sollte das Script in einem geringen Intervall gegen die zu prüfenden Datenbankinstanzen ausgeführt werden. Ein Intervall von z.B. 5 Minuten bedeutet, dass ein Verbindungsproblem spätestens nach 5 Minuten erkannt wird. Möchte man eine feinmaschigere Prüfung erreichen, so kann man das Intervall entsprechend reduzieren. Damit nicht alle Instanzprüfungen zeitgleich starten, habe ich zusätzlich eine Wartezeit von zwei Sekunden zwischen den Starts eingefügt (sleep).
Beispiel Cronjobs zur Prüfung von vier Datenbankinstanzen alle 5 Minuten:
# Oracle Instance Monitor Database Instances Every 5 Minutes */5 * * * * /home/oracle/scripts/instance_monitor/instance_monitor.sh orcl 2>&1 */5 * * * * sleep 2 && /home/oracle/scripts/instance_monitor/instance_monitor.sh db1 2>&1 */5 * * * * sleep 4 && /home/oracle/scripts/instance_monitor/instance_monitor.sh erpdb 2>&1 */5 * * * * sleep 6 && /home/oracle/scripts/instance_monitor/instance_monitor.sh dbprod 2>&1