UPDATE DBM CFG USING DFT_MON_BUFFPOOL ON DFT_MON_SORT ON DFT_MON_LOCK ON DFT_ MON_TIMESTAMP ON DFT_MON_UOW ON
Wie findet der Administrator heraus, was auf seinem Datenbankserver gerade los ist? Jahrelang hieß die Antwort immer LIST APPLICATIONS SHOW DETAIL, oft gefolgt von einer ganzen Kette von grep- und gegebenenfalls awk-Aufrufen, gesammelt entweder in der Shell History oder in einzelnen Shell-Skripten. Das Ergebnis liefert bestenfalls einen Hinweis darauf, dass z. B. eine Anwendung im Status LOCK WAIT oder aber schon seit einer langen Zeit im Status Executing ist. Für detaillierte Informationen über eine einzelne Anwendung muss dann ein Snapshot der Anwendung mit GET SNAPSHOT FOR APPLICATION APPLID <kryptische ID aus LIST APPLICATIONS> gefertigt werden, in dem man dann wieder mit grep nach den interessanten Zeilen suchen muss.
Die Abbildung 1 zeigt den Output von LIST APPLICATIONS SHOW DETAIL auf einer DB2 V9.7. Beachten Sie, dass hier gerade mal zwei aktive Clients auf einer Datenbank verbunden sind. Die restlichen sechs Einträge stammen z. B. vom „Self Tuning Memory Manager“ oder dem „Workload Manager Daemon“, die immer gestartet sind, uns aber in der Regel nicht wirklich interessieren. Abbildung 6 zeigt den deutlich übersichtlicheren Output unserer Lösung.
In den 7er-Versionen begann IBM mit der Einführung von Tabellenfunktionen zum direkten Zugriff auf Snapshot-Daten. Darauf basierend entstanden bis zur aktuellen Version 9.7 immerhin 64 administrative Views mit insgesamt 1.200 (teilweise redundanten) Spalten. Reichlich Informationen also, die man für individuelle Auswertungen nutzen kann (siehe Abbildung 2). Für unser Beispiel interessieren folgende Views:
Jede einzelne der insgesamt 179 Spalten ist im Information Center ausführlich dokumentiert. Allen gemeinsam ist die Spalte AGENT_ID, die wir zur sinnvollen Verknüpfung in Abfragen nutzen können und die zum Element APPLICATION HANDLE von LIST APPLICATIONS korrespondiert.
Ähnlich wie die unterschiedlichen Snapshot-Varianten benötigen auch die administrativen Views Zugriff auf Monitorelemente, die eingeschaltet sein sollten. Andernfalls sind die entsprechenden Spalten leer. Der Overhead für die Monitore wird unterschiedlich bewertet. Sollte das Einschalten der Monitor-Elemente zu Performance-Problemen führen, ist dies eher ein Hinweis, dass die Ressourcen insgesamt entweder knapp sind oder schlecht genutzt werden. Die Monitore schalten Sie dauerhaft in der DBM-Konfiguration ein (siehe Abbildung 3).
Aufgrund der großen Auswahl der verfügbaren Monitorelemente erscheint es zunächst schwierig, die vermeintlich richtigen auszuwählen. Unser Tipp: Blättern sie ein wenig durch die Views (z. B. mit der Steuerzentrale) und wählen Sie jeweils nur wenige, zusammenpassende Elemente aus. Entweder Sie erzeugen dann mehrere Skripte oder Sie entscheiden sich, die entsprechende Abfrage z. B. über Kommandozeilen-Argumente auszuwählen. Für unser Beispiel verwenden wir folgende Informationen:
Die resultierende Abfrage sehen Sie im Beispiel in Abbildung 4.
Das liefert schon eine brauchbare Übersicht über die aktiven Anwendungen einer Datenbank. Um die Systemprozesse auszuschließen, haben wir den Umstand genutzt, dass auch ohne explizite Verwendung des Workload Manager alle Prozesse implizit einer Workload zugeordnet werden. Die Workload „0“ bezeichnet damit Systemprozesse, die uns hier nur die Übersicht zerstören würden.
Mit dem Know-how aus dem ersten Teil dieser Reihe [1] sollte es uns nun leicht fallen, ein oder mehrere entsprechende Perl-Skripte zu erstellen. Spätestens ab der dritten Query wird der Quelltext allerdings recht unübersichtlich.
Für jede Query-Anpassung muss wieder der Programmcode editiert werden. Einzelne Abfragen möchte man evtl. auch in anderen Programmen verwenden und beim Editieren der SQL-Statements vergisst man leicht mal ein Anführungszeichen. Eine Lösung besteht darin, die SQL-Abfragen vom eigentlichen Programmcode zu trennen. Abstraktion schafft hier Flexibilität und Übersicht.
Das Perl-Modul SQL::Library bietet genau die gesuchte Funktionalität mit einer einfach zu handhabenden Schnittstelle. Sie erlaubt die Verwendung von SQL-Bibliotheken im Stil einer Windows INI-Datei, wobei jeder Abfrage ein eindeutiger Bezeichner zugeordnet wird.
Die ganze Arbeit von SQL::Library besteht daraus, einer Perl-Variable an entsprechender Stelle den Text der Abfrage zuzuweisen.
Die Installation erfolgt entweder über das CPAN-Modul mittels install SQL::Library oder über den üblichen Weg mit manuellem Download und der Befehlsfolge perl Makefile.pl; make; make install.
Abbildung 5 zeigt einen beispielhaften Auszug aus einer SQL::Library-Datei. In Abbildung 4 binden wir eine Abfrage aus der Library in unser Skript ein. Schon bei einer einzigen verwendeten Abfrage ist unser Skript deutlich schlanker und damit wartbarer geworden. Ein guter, erster Schritt.
Wir haben jetzt die SQL-Abfragen aus unserem Quellcode entfernt. Allerdings ist unser Skript noch recht starr auf eine Datenbank fixiert. Mit dem bisher Erlernten würden Sie ggf. für jede Datenbank ein Skript mit den jeweils geänderten Zugangsdaten erstellen. Viel einfacher wäre es, die Zugangsdaten für verschiedene Datenbanken in einer zentralen XML-Datei zu speichern und dann nur den Datenbanknamen über die Kommandozeile zu übergeben.
Im nächsten Teil beschäftigen wir uns mit dem Modul XML::Simple, das uns einfache Methoden hierfür zur Verfügung stellt.
Norbert Munkel (info@ordix.de).
