Manchmal vergisst man eine Aufgabe ganz elegant, weil sie langweilig geworden ist. Doch dann kommen die warnenden Mails von Cheffe und von sonstwo, die einen an die lästige Fertigstellung erinnern. Dabei ist Artikel schreiben doch wie programmieren. Sobald man den spannenden Teil geschrieben hat will man nichts mehr von dem lästigen Userinterface oder den Bugs wissen. Naja, ich kam nicht drum herum und musste mit das MaxDB Eventing anschauen.
MaxDB kennt rund 20 Events, die den Admin auf Wartungsaufgaben und anstehende Probleme aufmerksam machen. So kann das Kind seit Version 7.5.00.8 z.B. sagen, wenn es Hunger auf neuen Speicherplatz bekommt oder sich eine Aktualisierung der Optimizerstatistiken wünscht. Seit 7.6 wird der Event Dispatcher ausführlich dokumentiert und umworben. Zeit für ein paar Gehversuche mit MaxDB 7.6.00.12, die als Exkurs im Artikel verarbeitet wurden.
Ãœberblick
In MaxDB 7.6 findet sich ein neues Tool, der Event Dispatcher. Ein Event Dispatcher empfängt Nachrichten von einer MaxDB Datenbank Instanz und ruft bei Bedarf Handler auf, die auf die empfangenen Events reagieren. Der Event Dispatcher ist als eingenständiges Programm implementiert welches unabhängig von der Datenbank Instanz und der Kommunikationskomponente X-Server arbeitet. Ein Event Dispatcher überlebt also den Neustart von Datenbank Instanz und X-Server, nicht jedoch den Neustart des gesamten Rechners. Man muß sich also selbst darum kümmern den Event Dispatcher beim Booten der Maschine zu starten. Dieses Design als eigenständiges Programm ist notwendig, damit der Event Dispatcher auch einen Absturz oder einen kompletten Neustart der Datenbank protokollieren kann.
Jeder Event Dispatcher verfügt über eine eigene Konfigurationsdatei und ein eigenes Logfile. Ich halte es für ratsam beides endweder im Homeverzeichnis des sdb-Users oder – noch besser – im RUNDIRECTORY einer MaxDB Datenbank Instanz abzulegen. Pro MaxDB Datenbank Instanz können so viele Event Dispatcher lauschen und gestartet werden, wie in mit dem Datenbankparameter _MAXEVENTTASKS Tasks bereit gestellt werden. Das heißt also, daß MaxDB pro Event Dispatcher eine neue, interne Task startet und diese für für die Kommunikation mit dem Event Dispatcher abstellt. Andere Tasks werden also nicht mit der neuen Aufgabe des Dispatchings belastet.
Verfügbare Events
Das DBM Kommando event_list zeigt alle aktivierten Events. In der Ausgabe fehlen mindestens noch die “Special Events”. Die Special Events sind immer Aktiv und triggen, wenn sich etwas am Status des Event Dispatchers selbst ändert. Es gibt folgende Events: DISPINFO:DISPSTART, DISPINFO:DISPSTOP, DISPWARN:SHUTDOWN, DISPERR:DBCRASH, DISPERR:CONNLOST, DISPWARN:MISSEDEVT, DISPERR:NOEVENTTASK . Näheres hierzu findet sich im diesmal bemerkenswert vollständigen Handbuchkapitel.
./dbmcli on BW>event_list OK Name Priority Value Description DBFILLINGABOVELIMIT LOW 70 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT MEDIUM 80 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT MEDIUM 85 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 90 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 95 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 96 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 97 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 98 Filling of the database exceeds the given percentage DBFILLINGABOVELIMIT HIGH 99 Filling of the database exceeds the given percentage DBFILLINGBELOWLIMIT LOW 70 Filling of the database has fallen short of the given percentage DBFILLINGBELOWLIMIT LOW 80 Filling of the database has fallen short of the given percentage DBFILLINGBELOWLIMIT LOW 85 Filling of the database has fallen short of the given percentage DBFILLINGBELOWLIMIT LOW 90 Filling of the database has fallen short of the given percentage DBFILLINGBELOWLIMIT LOW 95 Filling of the database has fallen short of the given percentage LOGABOVELIMIT LOW 50 Filling of the log area exceeds the given percentage LOGABOVELIMIT LOW 75 Filling of the log area exceeds the given percentage LOGABOVELIMIT MEDIUM 90 Filling of the log area exceeds the given percentage LOGABOVELIMIT MEDIUM 95 Filling of the log area exceeds the given percentage LOGABOVELIMIT HIGH 96 Filling of the log area exceeds the given percentage LOGABOVELIMIT HIGH 97 Filling of the log area exceeds the given percentage LOGABOVELIMIT HIGH 98 Filling of the log area exceeds the given percentage LOGABOVELIMIT HIGH 99 Filling of the log area exceeds the given percentage AUTOSAVE LOW Automatic log backup was started BACKUPRESULT LOW The backup returned 0 or the system or error message given in value CHECKDATA LOW The check returned 0 or the system or error message given in value EVENT LOW An event was switched on or off ADMIN LOW Operational state was changed to ADMIN ONLINE LOW Operational state was changed to ONLINE UPDSTATWANTED LOW At least one table needs new optimizer statistics OUTOFSESSIONS MEDIUM Maximum number of parallel sessions is running ERROR HIGH A system error occured, see knldiag SYSTEMERROR HIGH A severe system error occured, see knldiag.err DATABASEFULL LOW The database is full and add data volume is necessary This event is only available in state online and du ring database recovery. LOGFULL LOW The log area is full and has to be saved LOGSEGMENTFULL LOW One log segment is full and can be saved STANDBY OFF So far event is switched off Operational state was changed to STANDBY --- ./dbmcli on BW>
Ein Event Dispatcher wird von der Datenbank nur über Events informiert, die zuvor aktiviert und konfiguriert wurden. Die obige Liste zeigt die bei einer Standardkonfiguration (7.6.00.12) automatisch aktivierten Events. Möchte man Handler für andere Events aufrufen, dann muß man diese zunächst in der Datenbank aktivieren. Sind sie nicht aktiviert, wird der Event Dispatcher nicht informiert und dieser wiederum kann den Handler nicht triggern. Die Aktivierung erfolgt mit dem DBM Kommando event_set. event_delete deaktivert ein Event. Wie aus der Hilfeausgabe der Kommandos hervorgeht, ist event_set auch das Kommando mit dem – je nach Event – Prioritäten und Schwellenwerte definiert werden können. Die Schwellenwerte kommen bei den Events zum Einsatz, die sich um die Speicherplatzverwaltung kümmern; DBFILLINGABOVELIMIT, DBFILLINGBELOWLIMIT, LOGABOVELIMIT. Es lassen sich also z.B. die Schwellenwerte ändern, um früher von Speicherplatzproblemen informiert zu werden.
linux:/opt/sdb/programs/bin # ./dbmcli -u DBADMIN,DBADMIN -d BW help event_set OK event_setLOW|MEDIUM|HIGH [ ] linux:/opt/sdb/programs/bin # ./dbmcli -u DBADMIN,DBADMIN -d BW help event_delete OK event_delete [ ]
Konfiguration erstellen
Das Executable des Event Dispatcher heißt dbmevtdisp und liegt an üblicher Stelle. Jeder Event Dispatcher verwendet ein Konfigurationsfile und ein Logfile. Leider entspricht das Format der Konfigurationsdatei keinem üblichen Standard, z.B. dem eines *.ini Files mit [abschnitten] und variable = wert Einträgen. Deshalb ist es ratsam nicht direkt in der Konfiguration zu arbeiten, sondern die in der Hilfeausgabe gezeigten Kommandos add, delete und list zu verwenden.
linux:/opt/sdb/programs/bin # ./dbmevtdisp MaxDB Event Dispatcher, Version 7.6.00.12 Copyright 2000-2005 by SAP AG invalid arguments. usage: addName == [Priority == (LOW|MEDIUM|HIGH)] [Value1 (==|>=|< =|>|< ) ] [Value2 (==|>=|< =|>|< ) ] Command == delete list start [-remoteaccess] -l -d (-u |-U ) [-n [-e SSL]] state -d (-u |-U ) [-n [-e SSL]] stop -d (-u |-U ) [-n [-e SSL]] version
Sofern eine Konfigurationdatei noch nicht existiert, wird sie implizit beim Aufruf von dbmevtdisp add erzeugt. Für die ersten Gehversuche mit Event Handlern kann man das ONLINE-Event verwenden. Es läßt sich angenehm einfach durch starten und stoppen der Datenbank erzeugen. Ähnlich gut geeignet für Tests ist AUTOSAVE.
Jedes Event ist mit einer Priorität verbunden. Manche Events sind zusätzlich mit einem numerischen Wert verknüpft. Bei der Erstellung eines Event Handlers muß man mindestens den Namen des Events angeben. Ein Handler der ohne Angabe von Priority und Value1 (numerischer Wert des Events, z.B. Schwellenwert für Speicherplatzevents) wird immer aufgerufen, wenn das Event eintritt das seiner Name Angabe entspricht. Ein Handler, der neben dem Namen auch noch unter Angabe einer Priority konfiguriert wurde, wird nur dann aufgerufen, wenn das konfigurierte Event eintritt und die Datenbank eine Priorität meldet, die der konfigurierten Priority entspricht.
Ganz einfach gesagt feuert ein Handler, der mit Name == DBFILLINGABOVELIMIT immer, wenn die Datenbank das Event sendet, egal wie die Priorität ist und welcher Füllgrad erreicht wurde. Das ist in der Standardkonfiguration bei einem Füllgrad von 70%, 80%, 85%, 90%, 95%, 96%, 97%, 98% und 99% der Fall (siehe event_list Ausgabe). Der Handler mit Name == DBFILLINGABOVELIMIT und Priority == MEDIUM feuert bei 80% und 8%. Und ein Handler mit Name == DBFILLINGABOVELIMIT, Priority == HIGH und Value1 >= 97 könnte benutzt werden um bei den letzten 3 Warnungen vor dem GAU deutliche Worte an den Datenbankadministrator zu richten. Wie man sieht ist es also auch möglich mehrere Handler für ein Event zu definieren.
Änderungen an der Konfigurationsdatei eines Event Dispatchers bedürfen keine Neustart desselben. Neueinträge werden automatisch erkannt.
Genug der Worte, es wird Zeit für den ersten, einfachen Event Handler. Eine Hürde bei meinen ersten Gehversuchen mit Events war die Shell. Nicht immer habe ich die notwendigen Escapezeichen verwendet, was zu Fehlern beim Aufruf des Handlers führte. Also aufpassen.
linux:/opt/sdb/programs/bin # ./dbmevtdisp add /var/opt/sdb/data/wrk/BW/myevt.cfg Name == AUTOSAVE Command == "/bin/bash -c "echo '\$EVTDATE$ \$EVTTIME$ \$EVTNAME$ ' >> /tmp/maxdb_events.log" "
OK
11
Mit dem Kommando wird ein denkbar einfacher Event Handler für das Event AUTOSAVE definiert. AUTOSAVE gehört zum automatischen Logbackup von MaxDB. Der Handler wird mit Command = "..." angegeben. Aufgerufen wird der Handler mit den Rechten desjenigen, der den Event Dispatcher gestartet hat. Wird der Event Dispatcher von root gestartet ist also vorsicht geboten. Andererseits ist bei Verwendung eines anderen Users zu prüfen ob dieser das angegebene Kommando überhaupt ausführen darf.
Im Beispiel wird die bash benutzt, um per echo-Aufruf Ausgaben in ein einfaches Logfile zu schreiben. Im Kommando sind einige Variablen enthalten, die der Event Dispatcher zum Zeitpunkt des Aufrufs ersetzt. $EVTDATE$ und $EVTTIME$ enthalten das aktuelle Datum und die aktuelle Uhrzeit, $EVTNAME$ speichert den Namen des Events. Die verfügbaren Variablen sind im Handbuch beim add-Kommando des Event Dispatchers aufgelistet. Unter anderem wird die Variable $DBMUSERPW$ aufgeführt. Es ist unschwer zu erraten was hier gespeichert wird, also Vorsicht, damit nicht jeder im Log ein Passwort vorfindet…
Der Rückgabewert 11 des add-Komanndos besagt, daß es das 12. Kommando ist, welches ich in der Konfigurationsdatei /var/opt/sdb/data/wrk/BW/myevt.cfg abgelegt habe. MaxDB beginnt die Zählung bei 0 und antwortet auf den allerersten add-Aufruf auch mit 0. Die Nummer ist wichtig, weil sie dazu dient Handler zu identifizieren.
Jetzt endlich kann der Event Dispatcher gestartet werden. Da sich der Event Dispatcher an der Datenbank anmelden muß, sind DBM Zugangsdaten anzugeben. Näheres zu den notwendigen Rechten ist im Handbuch bei der Beschreibung des start-Kommandos beschrieben.
linux:/opt/sdb/programs/bin # ./dbmevtdisp start /var/opt/sdb/data/wrk/BW/myevt.cfg -l /var/opt/sdb/data/wrk/BW/myevt.log -d BW -u DBADMIN,GEHEIM Event Dispatcher instance 4 running
Nach dem Start des Event Dispatchers wird als erstes eine Instanznummer ausgegeben. Diese wird benötigt, um den Event Dispatcher beim stopp-Kommando identifizieren zu können.
linux:/opt/sdb/programs/bin # ./dbmevtdisp stop 4 -d BW -u DBADMIN,DBADMIN OK
Start – Ziel Sieg?
Mir gefallen die neuen Eventing-Funktionen sehr gut. Ein paar Dinge konnte man schon vorher über Umwege erreichen, aber es waren halt Umwege. Jetzt geht es direkt.
Das einzige was mich beim Test gestört hat, war das Format der Konfigurationsdateien. Es ist lästig bei der Erstellung von neuen Handlern auf die korrekte Syntax zu achten. Manchmal mischt sich die Shell ein und verlangt zusätzliche Kentnisse von mir wie ich mit der Shell arbeite. Eine GUI wäre eine weitere Bereicherung. Trotzdem: praktische Sache. Ohne Tools von Drittanbietern gelingt ein Monitoring der Datenbank. Eine logische Entwicklung für MaxDB.
Pingback: Internet Super Hero » Blog Archive » MaxDB und die Statistiken
Pingback: Internet Super Hero » Blog Archive » MaxDB starten und stoppen