Quelle: John Collier (Wikipedia Public Domain)

Viele wollen die oft genutzte Datenbank monitoren: Hersteller professioneller Tools, die mit SQL-Code und Betriebssystembefehlen prüfen und über sich anbahnende Probleme im Voraus informieren, genauso wie Oracle seit 10g selbst mit DB Control. Doch ein Satz eigener Skripte schafft das im Prinzip auch.

Alexander der Große soll 335 vor Christus in Delphi [1] die Orakel-Priesterin Pythia an den Haaren in den Tempel gezerrt haben, weil sie ihm die Auskunft verweigerte. Daraufhin soll sie gerufen haben: “Lass ab von mir, du bist doch unüberwindlich, Junge!” Alexander, der in den Krieg ziehen wollte, war zufrieden: “Jetzt habe ich meine Antwort!”

Um heute über die Leistungsfähigkeit einer Datenbank Aufschluss zu erhalten, sind keine so drastischen Maßnahmen nötig, wohl aber wirksame. Denn kein Oracle-Administrator möchte zum Beispiel vom Datenwachstum seiner Datenbank überrascht werden und will den Ausfall einer Oracle-Instanz bemerken, bevor die Anwender anrufen und sich beklagen. So stellen Firmen wie Oracle, BMC und Quest professionelle Monitoring-Tools her, die in große heterogene Umgebungen gut einzubetten sind.

Sie führen eine End-to-End-Analyse aus: Vom Frontend der Applikation über das Netzwerk bis in das Backend zum Datenbankserver monitoren sie alle Komponenten in Echtzeit. Oracle selbst [2] offeriert seit seiner letzten Major Release 10g ein Werkzeug in der Box: Oracle DB Control. Die grafische, mausbediente Webapplikation informiert über die Anzahl der aktiven Sessions, den Datenbankdurchsatz und andere Werte (Abbildung 1).

Abbildung 1: Oracle Database Control, das Web-basierte Monitoring-Werkzeug für einzelne Datenbanken, ist ab Release 10g serienmäßig dabei.

Hier kann der Admin auch einstellen, dass er Kennzahlen wie Speicherauslastung und Ressourcenbedarf, Verfügbarkeit und wichtige Fehlermeldungen über SMTP gemailt bekommt. Etwas umfangreicher und damit gut für größere Umgebungen geeignet ist Oracle Grid Control. In dem Toolset lassen sich neben den Datenbanken weitere Ziele wie der Host selbst oder der Oracle Application Server monitoren. Seine Funktionalität ist mit eigenen Skripten erweiterbar.

Drittanbieter

Der Softwarehersteller Quest bietet mit Central [3] eine gut integrierbare Lösung feil. Die grafische Oberfläche erlaubt Datenbankdiagnose und Performance-Monitoring, Storage-Management und SQL-Tuning. Eine Ergänzung heißt Quest Foglight, das komplexe Datenbankumgebungen rund um die Uhr monitort und potenzielle Engpässe entdecken hilft. Der Admin darf sich zudem via E-Mail – ähnlich wie bei anderen Monitoring-Tools – benachrichtigen lassen.

Die texanische Firma BMC wiederum hat eine breite Palette an Monitoring-Agenten im Portfolio, darunter den Patrol Oracle Performance Manager (siehe Abbildung 2, [4]). Die Checks betreffen die Verfügbarkeit der Datenbankinstanz und des Oracle Listener sowie die Speicherauslastung von Tablespaces. Auch überwacht das Tool Fehlermeldungen des Alert-Log (siehe weiter unten).

Abbildung 2: Der Dritthersteller BMC bindet die gesamte Umgebung in das Monitoring ein.

Schläge ins Kontor

Solche Rundum-sorglos-Pakete aus dritter Hand identifizieren Probleme schnell und umfassend. Die Lizenzkosten jedoch drücken bei kleinen und mittelständischen Unternehmen aufs IT-Budget. Hier können Werkzeuge Marke Eigenbau sicherlich etwas Luft schaffen. Denn Oracle bietet mit internen Views und dem Wait Interface gute Voraussetzungen, interne Abläufe genau zu prüfen.

So können einfache Skripte Informationen über Benutzer, Sperren und gerade ausgeführte SQL-Statements einholen. Auch Engpässe für die gesamte Oracle-Instanz sowie Ressourcen wie CPU und Platten-I/O sind prüfbar, ebenso wie die Ursache hängender Sessions. Last but not least: Entwicklungen des Verbrauchs an Plattenplatz, der Fragmentierung der Datensegmente oder auch die Qualität von Indizes kann jeder Admin mit Datenbank-eigenen Mitteln implementieren. Notwendig sind dazu lediglich einige Shellskripte und SQL-Statements.

Verfügbarkeit von Oracle-Instanzen prüfen

Der wichtigste Check im Datenbank-Alltag zielt allerdings sicherlich auf die Verfügbarkeit, also ob sich Benutzer zur Datenbank verbinden können. Auf Unix-Systemen darf er hierzu die Datei Oratab heranziehen. Sie verzeichnet alle Oracle-Instanzen, die das System startet. Der Aufbau der Einträge entspricht dem folgenden Schema:

SID:Oracle-Home:Autostart

SID steht für System Identifier und meint den Namen der Oracle-Instanz. Oracle Home ist das Verzeichnis mit den Oracle-Binaries, das die Instanz verwendet. Autostart kann mit »Y« oder »N« belegt sein und bestimmt, ob beim Booten des Systems die Oracle-Instanz automatisch anläuft. Den typischen Inhalt einer Oratab zeigt Listing 1. Die Datei informiert, welche Datenbanken auf dem System laufen sollten. Welche im Moment tatsächlich aktiv sind, verrät die Prozessliste. Denn jede Oracle-Instanz erzeugt beim Start einen Satz typischer Hintergrundprozesse. Deren Vorhandensein wiederum erlaubt zu überprüfen, ob eine Oracle-Instanz auch tatsächlich läuft.

01 #########################################
02 ## /var/opt/oracle/oratab
03 #########################################
04 oradb1:/u01/app/oracle/product/9.2.7:Y
05 oradb2:/u01/app/oracle/product/10.1.0:Y
06 oradb3:/u01/app/oracle/product/10.2.0:Y
07 oradb4:/u01/app/oracle/product/8.1.7:N

Einer der Oracle-Background-Prozesse nennt sich System Monitor, kurz SMON. In der Prozessliste zeigt er sich für jede einzelne Instanz. Die Bezeichnung lautet »ora_smon_SID«, wobei das Kürzel SID wieder für den System Identifier – den Namen der Oracle-Instanz – steht, beispielsweise »ora_smon_oradb1« bis »ora_smon_oradb4«.

Oratab und Prozessliste

Um zu prüfen, ob alle auf dem System vorhandenen Oracle-Instanzen laufen, kann man einfach per Skript die Datei Oratab auslesen, die im System vorhandenen Instanzen überprüfen und dann in der Prozessliste nach dem passenden SMON-Prozess zu schauen. Führt die Prozessliste keinen passenden SMON, läuft die zugehörige Oracle-Instanz derzeit nicht. Listing 2 zeigt ein Beispiel zur skriptgesteuerten Prüfung.

01 #####################################################
02 # simple_check_instance.ksh
03 #####################################################
04 ORATAB=/var/opt/oracle/oratab
05 echo "`date`   "
06 echo " Status der Oracle-Instanzen auf `hostname` :n"
07 
08 db=`egrep -i ":Y|:N" $ORATAB | cut -d":" -f1 | grep -v "#" | grep -v "*"`
09 pslist="`ps -ef | grep pmon`"
10 for i in $db ; do
11   echo "$pslist" | grep  "ora_smon_$i" > /dev/null 2>$1
12   if (( $? )); then
13     echo "Oracle Instance - $i:       Down"
14   else
15     echo "Oracle Instance - $i:       Up"
16   fi
17 done

Das Skript benötigt noch Ausführungsrechte: »chmod 744 simple_check_instance.ksh«. Wer es aufruft, erhält eine Ausgabe wie diese:

Son Feb  11 08:30:05 PST 2007
Status der Oracle-Instanzen auf suntest01:
Oracle Instance - oradb1:   Up
Oracle Instance - oradb2:   Up
Oracle Instance - oradb3:   Down
Oracle Instance - oradb4:   Up

Sie zeigt an, dass die Oracle-Instanz »oradb3« nicht verfügbar ist. Der Nachteil des Skripts ist, dass der Admin es manuell ausführen und auswerten muss. Besser wäre eine Automatik, die den Datenbank-Beaufsichtiger per Mail benachrichtigt, wenn die Instanz nicht hochgefahren ist. Zudem möge das Konstrukt Meldungen in ein Logfile schreiben, ob die Oracle-Instanz verfügbar ist oder nicht. Das Listing 3 erweitert Listing 2 um das gewünschte Verhalten. Der automatische Aufruf erfolgt per Crontab-Eintrag. Das Vorgehen für dieses und die anschließend vorgestellten Skripte erklären der Kasten “Crontab zum Monitoring” und Listing 4.

01 #M    S   T   M   W    Befehl
02 5     *   *   *   *     /opt/oracle/admin/scripts/check_instance.ksh > /dev/null 2>&1
03 */5   *   *   *   *     /opt/oracle/admin/scripts/check_lsnr.ksh > /dev/null 2>&1
04 59    23  *   *   0     /opt/oracle/admin/scripts/clean_arch.ksh > /dev/null 2>&1
05 0     0   *   *   *     /opt/oracle/admin/scripts/check_tablespace.sh > /dev/null 2>&1
06 30    1   *   *   1-5   /opt/oracle/admin/scripts/invalid_objects.sh > /dev/null 2>&1
07 30    1   *   *   1-5   /opt/oracle/admin/scripts/deadlock_alert.sh > /dev/null 2>&1
08 30    1   *   *   1-5   /opt/oracle/admin/scripts/check_alertlog.sh > /dev/null 2>&1

01 ###########################################################################
02 # check_instance.ksh
03 ###########################################################################
04 ORATAB=/var/opt/oracle/oratab
05 LOGFILE=/opt/oracle/admin/logs/inst.log
06 DBALIST="dba-group@domain.de,admin@firma.de;
07 export DBALIST
08 
09 echo "`date`   "
10 echo " Status der Oracle-Instanzen auf `hostname` :n"
11 
12 db=`egrep -i ":Y|:N" $ORATAB | cut -d":" -f1 | grep -v "#" | grep -v "*"`
13 pslist="`ps -ef | grep pmon`"
14 for i in $db ; do
15    echo  "$pslist" | grep  "ora_smon_$i" > /dev/null 2>$1
16    if (( $? )); then
17       echo "Oracle Instance - $i:       Down" > $LOGFILE
18       echo "Alert" | mailx -s "Instanz auf `hostname` ist down" $DBALIST
19    else
20       echo "Oracle Instance - $i:       Up" > $LOGFILE
21    fi
22 done

Lauscht da wer?

Dass die Instanz läuft, liefert nur ein Indiz für die Verfügbarkeit. Denn: Versucht ein Benutzer sich zu einer Instanz zu verbinden, geht das nur über einen speziellen Vermittlerprozess, den Oracle Listener. Der lauscht auf Anfragen, nimmt sie entgegen und stellt die eigentliche Verbindung zur Oracle-Instanz her.

Da ohne den Listener die Datenbank für die Clients nicht erreichbar wäre, muss der Admin dessen Gesundheitszustand prüfen. Der Befehl »lsnrctl status Listener _Name« oder Listing 5 helfen weiter. Besser noch, als eine Nachricht zu versenden, ist es, den Listener gleich nachzustarten. Dazu erweitert Listing 6 das Listing 5. Die grundlegende Betriebsfähigkeit des Systems wäre mit den Skripten in Listing 2 und 5 also gesichert.

01 ###############################################
02 # check_lsnr.ksh
03 ###############################################
04 #!/bin/ksh
05 
06 cd /var/opt/oracle
07 rm -f lsnr.exist
08 ps -ef | grep MeinListener | grep -v grep > lsnr.exist
09 if [ -s lsnr.exist ]
10 then
11    echo "Alles ok!" >> check_lsnr.log
12 else
13    echo "Alert" | mailx -s "Listener 'MeinListener' on `hostname` laeuft nicht" dba-group@domain.de
14 fi

08 [...]
09 if [ -s lsnr.exist ]
10 then
11     echo
12 else
13    echo "Alert" | mailx -s "Listener 'MeinListener' on `hostname` laeuft nicht" dba-group@domain.de
14    lsnrctl start MeinListener
15 fi

Wichtige Logfiles

Eine zentrale Oracle-Logdatei ist das Alert-Log. Es liegt in der so genannten Background Dump Destination, einem Verzeichnis, das Oracle als Aufenthaltsort für Log- und Tracefiles der Hintergrundprozesse vorsieht. Das Alert-Log verzeichnet Starts und Shutdowns jeder Oracle-Instanz, Informationen zu Redo Log Switches und Checkpoints. Auch die Parametrisierung der Oracle-Instanzen findet hier einen Niederschlag.

Bedeutender sind harte Fehlermeldungen, etwa wenn eine Instanz auf eine Datenbankdatei nicht zugreifen kann oder deren physische Validität unklar ist. Block-Korruptionen etwa, Veränderungen einer einzelnen Datenseite, die zur Unlesbarkeit des gesamten Datenblocks führen, sind hier ebenso verzeichnet wie das Fehlen einer Datendatei oder schwerwiegende interne Fehler.

Die relevanten Error-Messages beginnen stets mit dem Kürzel »ORA« gefolgt von einer Fehlernummer. Dies gibt die Möglichkeit, nach genau diesem Kürzel mit »grep« zu suchen und entsprechende Fehlermeldungen an die Kolleginnen und Kollegen der Datenbankadministration zu mailen. Das kann in etwa so aussehen wie in Listing 7.

01 ###############################################
02 # check_alertlog.ksh
03 ###############################################
04 # Gehe in das Zielverzeichnis
05 cd $ORACLE_BASE/admin/oradb2/bdump
06 # Ein Alert.log zur Oracle-Instanz vorhanden?
07 if [ -f alert_oradb2.log ]
08 then
09   # Grep bzw. Suche nach Zeichenfolgen mit ORA-
10   # und gebe diese in die Datei alert.err aus
11   grep ORA- alert_oradb2}.log > alert.err
12 fi
13 
14 # Mehr als 0 Zeilen in alert.err zu finden?
15 if [ `cat alert.err|wc -l` -gt 0 ]
16 then
17   Maile an die Oracle-DBAs
18   mailx -s "oradb2: ORACLE ALERT ERRORS" dba-group@domain.de < alert.err
19 fi

Archivierung von Redo-Logfiles und Plattenplatz

Oracle ist bekannt für Stabilität – selbst harte Unterbrechungen seiner Arbeit nimmt das System nur selten übel. Der Admin kann zudem im Fehlerfall jeden konsistenten Zustand der Datenbank wiederherstellen. Neben dem Backup der Datenbank selbst zieht er dabei Archived Redo Logs heran, sie dienen Oracle als Transaktionsprotokoll, das jede Änderung der Daten festhält.

Um Platz zu sparen, überschreibt die Engine ihre Redo-Logfiles zyklisch. Wer den Langzeitgedächtnisverlust verhindern will, muss die Logdateien archivieren. Bei einem Recovery der Datenbank bringen archivierte Redo-Logs Vorteile, denn so lassen sich auch ältere Zustände zurückholen. Einziger Nachteil: Wenn man nicht ab und zu aufräumt, läuft der Plattenplatz fürs Archiv voll.

Das Skript aus Listing 8 prüft den Plattenplatz aller Archive-Verzeichnisse des Systems und sichert ältere Archived Redo Logs mit dem Recovery Manager (RMAN). Der ist Bestandteil jeder Oracle-Installation und hilft beim Sichern von Datenbankdateien und Archive Redo Logs. Letztere vermag das Werkzeug nicht nur zu sichern, sondern entfernt sie anschließend auch aus dem Filesystem. Statt des RMAN-Aufrufs in Zeile 5 (Listing 8) dürfte auch ein anderes Tool wie »cpio« oder »tar« stehen oder – wohl seltener – ein »rm« seinem zerstörerischen Wesen nachkommen.

01 ###############################################
02 # clean_arch.ksh
03 ###############################################
04 #!/bin/ksh
05 sicherungsskript=/opt/oracle/admin/scripts/rman_arch.sh
06 df -k | grep arch > dfk.result
07 archive_filesystem=`awk  -F" "  '{ print $6 }' dfk.result`
08 archive_kapazitaet=`awk  -F" "  '{ print $5 }' dfk.result`
09 if [[ $archive_ kapazitaet> 90% ] ]
10 then
11    echo "Filesystem ${archive_filesystem} ist zu ${archive_kapazitaet} gefuellt"
12    find $archive_filesystem -type f -mtime +2 -exec rman_arch.sh
13 fi

Und der Speicherplatz?

Oracle organisiert seine persistenten Daten in eigenen Speicherbereichen auf Festplatte, den so genannten Tablespaces. Objekte wie Tabellen und Indizes sind hier gespeichert. Tablespaces können autoextensibel sein, sie erweitern sich bei Bedarf automatisch. Viele Admins ziehen es aber vor, den Tablespace selbst zu überwachen und Plattenplatz zuzuweisen, statt die Ressourcen den Anwendern zu überlassen.

Läuft der Speicherplatz – warum auch immer – in einem Tablespace voll, sind zwar noch Abfragen des Datenbestands möglich, aber keine Erfassung mehr. Der charakteristische Fehler »Can not allocate next extent« ist wohl jedem Datenbank-Administrator bekannt. Um ihm zu entgehen, empfiehlt es sich, die Auslastung der Tablespaces zu monitoren. Dafür ist der Zugriff auf interne Tabellen mit SQL erforderlich. Mit SQL*Plus, einem Kommandozeilewerkzeug, das jede Oracle-Installation mitbringt, lässt sich das leicht bewerkstelligen. Es eignet sich prima fürs automatisierte Scripting und Monitoring. Die aus den SQL-Befehlen entstandenen SQL*Plus-Ausgaben lassen sich anschließend auswerten.

Listing 9 übergibt einfach eine entsprechende SQL-Abfrage an SQL*Plus. Das Skript ruft dazu SQL*Plus auf und erzeugt ein Spoolfile, das die Ausgabe des SQL-Statements aufnimmt. Das SQL-Statement selbst fragt interne Oracle-Views ab, darunter die View »dba_data_files«, in der die Namen aller Datenbankdateien stehen, und »dba_free_space«, in der Informationen über den freien Speicher zu finden sind.

01 #############################################
02 #  check_tablespace.sh
03 #############################################
04 #!/bin/ksh
05 . /etc/oracle.profile
06 
07 sqlplus -s <<!
08 "/ as sysdba
09 
10 -- Start der Formatierung der Ausgabe
11 set feed off
12 set lines 3000
13 set pages 3000
14 set trimspool on
15 set trimout on
16 column Tablespace          format a30
17 column "Size MB"           format 999,999,999,999
18 column "Used MB"           format 999,999,999,999
19 column "Free MB"           format 999,999,999,999
20 column "% Used"            format 999.99
21 -- Ende der Formatierung der Ausgabe
22 
23 -- Spool der Ausgabe in die tablespace.alert:
24 spool tablespace.alert
25 
26 -- Start des SQL-Statements
27 select
28   tablespace_name                      "Tablespace",
29   round(bytes/1048576)                 "Size MB",
30   round(nvl(bytes-free,bytes)/1048576) "Used MB",
31   round(nvl(free,0)/1048576)           "Free MB",
32   nvl(100*(bytes-free)/bytes,100)      "% Used"
33 from(
34   select
35      ddf.tablespace_name,
36      sum(dfs.bytes) free,
37      ddf.bytes bytes
38   from (
39      select tablespace_name, sum(bytes) bytes
40      from dba_data_files
41      group by tablespace_name
42      ) ddf,
43      dba_free_space dfs
44   where ddf.tablespace_name = dfs.tablespace_name(+)
45   group by ddf.tablespace_name, ddf.bytes
46      )
47 -- Berechnung des Fuellgrades:
48 where nvl(100*(bytes-free)/bytes,100) > 90
49 ;
50 -- Ende des SQL-Statements
51 
52 spool off
53 exit
54 !
55 if [ `cat tablespace.alert|wc -l` -gt 0 ]
56 then
57    mailx -s "TABLESPACE voll" dba-group@domain.de < tablespace.alert
58 fi

Die letzte Zeile des SQL-Statements enthält eine Where-Klausel, sie bestimmt Datenzeilen mit Speicherbereichen, deren Füllgrad mehr als 90 Prozent beträgt. Ist dieser Wert überschritten, schickt das Skript abschließend eine Mail an einen Administrator mit dem Betreff »Tablespace voll« und dem Inhalt des Spoolfile. Mit SQL-Statements und SQL*Plus lassen sich auf diesem Wege so ziemlich alle internen Informationen der Datenbank prüfen. Dem Monitoring-Bastler sind hier kaum Grenzen gesetzt.

Invalide und Deadlocks

Zwei weitere Beispiele aus der Praxis demonstrieren, wie sich einfache SQL-Abfragen in Betriebssystemskripten nutzen lassen. Die Oracle-View »dba_objects« liefert Informationen über alle Datenbankobjekte, darunter das Erstellungsdatum und den Status eines Objekts. Verharrt ein Objekt im Status »invalid«, ist es nicht kompilier- und damit nicht benutzbar. Das ist in Entwicklungsdatenbanken kein Beinbruch, in produktiven Systemen aber schädlich. Listing 10 zeigt ein Skript, das auf invalide Objekte prüft.

01 ###############################################
02 # invalid_objects.sh
03 ###############################################
04 #!/bin/ksh
05 . /etc/oracle.profile
06 sqlplus -s <<!
07 oracle/$1@$2
08 set          feed off
09 set heading off
10 column object_name format a30
11 spool invalid_object.alert
12    SELECT  OWNER, OBJECT_NAME, OBJECT_TYPE, STATUS
13    FROM    DBA_OBJECTS
14    WHERE   STATUS = 'INVALID'
15    ORDER BY OWNER, OBJECT_TYPE, OBJECT_NAME;
16 spool off
17 exit
18 !
19 if [ `cat invalid_object.alert|wc -l` -gt 0 ]
20 then
21     mailx -s "Invalide Objekte" meinDBA@meineFirma.de < invalid_object.alert
22 fi

Die letzte Monitoring-Aufgabe des Artikels widmet sich Datenbanksperren. Die führen gern zu ernsthaften Problemen, etwa dem Abbruch einer lange laufenden Transaktion. Glücklicherweise sind Sperren über die Datenbank-View »V$LOCK« erkennbar. Das Listing 11 fragt darum die View ab und benachrichtigt, wenn eine Sperre vorliegt. Der Mailbody listet dann blockierende und wartende Sessions.

01 ###############################################
02 # deadlock_alert.sh
03 ###############################################
04 #!/bin/ksh
05 . /etc/oracle.profile
06 sqlplus -s <<!
07 oracle/$1@.$2
08 set feed off
09 set heading off
10 spool deadlock.alert
11    SELECT   SID, DECODE(BLOCK, 0, 'NO', 'YES' ) BLOCKER,
12                  DECODE(REQUEST, 0, 'NO','YES' ) WAITER
13    FROM     V$LOCK
14    WHERE    REQUEST > 0 OR BLOCK > 0
15    ORDER BY block DESC;
16 spool off
17 exit
18 !
19 if [ `cat deadlock.alert|wc -l` -gt 0 ]
20 then
21    mailx -s "DEADLOCK ALERT for ${2}" meinDBA@meineFirma.de < deadlock.alert
22 fi

Fazit: Je nach Geldbeutel

Angesichts der Marktbedeutung von Oracle überrascht es wenig, dass Administratoren mit großem Budget bei kommerziellen Herstellern fündig werden, wenn sie mächtige und übersichtliche Monitoring-Werkzeuge suchen. Doch auch mit Bordmitteln ist die Validitätsprüfung der Datenbank möglich – so mit dem Web-basierten Oracle DB Control ab 10g. Wer das nicht mag oder eine ältere Release betreibt, kommt mit den hier gezeigten Skripten, die mit SQL- und Betriebssystembefehlen umfangreich und präventiv informieren, auch zum Ziel. (jk)