| XM4DB2 bietet permanente Kontrolle von aufgabekritischen DB2 Subsystemen. Im Hintergrund arbeitend, prüft das Programm die Verfügbarkeit von DB2 Objekten und die Betriebsbereitschaft von Utilities, Plänen und Packages. Es erkennt und meldet drohende Platzknappheit von Tablespaces und Indexspaces. Das Programm verwaltet und zeigt eine Tabelle der aktuellen "Exceptions" und alarmiert die Datenbank- und System-Administration über wichtige Dinge per Email. Es bietet eine Funktion, um Standardsituationen automatisch zu reparieren. |
 |
Einführung
DB2 Systeme sind permanent in Bewegung. Daten werden von verschiedenen Anwendungen eingefügt, geändert und gelöscht. Utilities reorganisieren, prüfen oder sichern Daten. Alles ist in Bewegung und so soll es sein. Viele der Aktivitäten erzeugen Nachrichten und Warnungen. DB2 erzeugt permanent Informationen über eingetretene Ereignisse, Objekte, die nur eingeschränkt verfügbar sind, und es erzeugt Warnungen und Berichte zu Fehlern. Es erfordert eine Menge Arbeit diese Flut von Informationen einzusehen, zu bewerten und die relevanten Informationen herauszuholen. Erschwerend kommt hinzu, dass es meistens nicht ausreicht nach bestimmten Nachrichten zu suchen oder die Ausgaben einer Reihe von Display-Kommandos zu analysieren. Die frühe Erkennung von unerfreulichen Störungen erfordert es, verschiedene Informationsquellen zu prüfen und Rückschlüsse aus mehr als einer Beobachtung zu ziehen.
Hier ein einfaches Beispiel:
Solange ein Load-Utility auf einen Tablespace zugreift, ist es normal, das dieser in den Status "RECP" versetzt wird. Bricht jedoch das Load-Utility ab und der Tablespace verbleibt in dem Status, dann muss sich jemand um diesen Fall kümmern. Das heißt, ein eingeschränkter Status alleine ist noch kein Problem. Man muss prüfen, ob der Status einen normalen Grund hat und die weitere Entwicklung verfolgen.
Kein Möglichkeiten in DB2
Bestimmte Probleme, wie drohender Platzmangel, sind nicht mit den Möglichkeiten von DB2 alleine zu erkennen. Dazu ist es nötig Informationen aus dem z/OS Katalog zu holen. Üblicherweise ist es notwendig mehrere Indikatoren zu sammeln und einige Berechnungen anzustellen um definitiv sagen zu können, dass ein Tablespace voll laufen wird.
Unterm Strich
Hunderte von Nachrichten und Warnungen, ungefähr 30 mögliche, eingeschränkte Zustände von tausenden Tablespaces in einer Reihe von DB2 Subsystemen und eine Reihe ausschlaggebender Ereignisse in DB2 oder im Betriebssystem sind schwer mit bloßem Auge zu überwachen. Es ist angemessen, und an vielen Stellen unumgänglich, diese schwierige Arbeit der ununterbrochenen Überwachung von DB2 und seiner Umgebung einem Programm zu übergeben.
Hierfür wurde XM4DB2 - The Exception Monitor for DB2 - entwickelt
XM4DB2 sucht unaufhörlich nach Ausnahmezuständen und nach Indikatoren für aktuelle oder künftige Probleme und alarmiert die zuständigen DBAs. Es gibt mehrere Überwachungsprogramme für DB2 und/oder z/OS auf dem Markt, aber unseres Wissens missen sie alle die Möglichkeit verschiedene Beobachtungen zu kombinieren und sie überwachen alle nur bereits aufgetretene Probleme. Wie bereits erwähnt, Tablespaces mit eingeschränkter Verfügbarkeit sind normal, es können mehrere hundert Tablespaces gleichzeitig eingeschränkt sein. Der Grund muss gesucht und der Zustand verfolgt werden. Sowie erkennbar ist, dass es eine nicht akzeptierbare Situation gibt, für die DB2 oder eine andere Komponente keine automatische Lösung findet, wir nennen es Exception, muss unverzüglich eine Warnung ausgegeben werden. Eine Exception erfordert das Handeln der Datenbank Administration. Typischerweise wird eine Exception als Resultat mehrerer Indikatoren erkannt. Es gibt Platz für Verbesserungen.
Warum nicht vordefinierte Lösungen anbieten?
Eine Exception, die wiederholt zu einem bestimmten Fehler führt und die nicht vermeidbar scheint, braucht eine generelle Behandlung. XM4DB2 bietet Aktionen, die im Grunde vordefinierte Reparatur-Jobs sind, die in gegebenen Situationen anwendbar sind. Diese Jobs müssen vom DBA geprüft, ergänzt und submittet werden. In einigen Fällen können diese Jobs auch über einen Scheduler submittet werden. XM4DB2 ist lernfähig, es beinhaltet schon einige vordefinierte Abläufe, das heißt Ansätze von Lösungen, aber noch interessanter ist, dass es einfach ist neue Abläufe zu definieren.
Benutzerdefinierte Beobachtungen
Benutzer können aber nicht nur Abläufe definieren, sie können außerdem eine Reihe von Beobachtungen als Exception definieren, die dann überwacht und gemeldet werden, wie jede andere Exception.
Übersicht
XM4DB2 "kennt" komplexe Regeln um Exceptions zu erkennen. Es prüft Tablespaces, Utilities und andere Sachen in benutzerdefinierten Intervallen und meldet kritische Situationen per Email. So wird die Datenbank-Administration von der lästigen Arbeit des Auswertens und Analysierens einer Flut von Daten befreit. Die Administration wird von der fehleranfälligen Arbeit des Ausführens verschiedener Display-Kommandos und Auswertens komplexer Ausgaben befreit. XM4DB2 ist der Schnüffler, der Privatdetektiv, der die harte Arbeit ausführt. Die DBA konzentriert darauf XM4DB2 mehr und mehr Exceptions beizubringen und wie diese gelöst werden.
Alles hängt von der Verfügbarkeit von aufgabekritischen Anwendungen ab und so müssen DB2 Objekte ständig verfügbar sein. Die fortwährende Überwachung von DB2 ist so unabdingbar wie lästig für die DBA. XM4DB2 entlastet das Betriebspersonal, beugt Fehlern vor, folglich steigert XM4DB2 die Verfügbarkeit.
Struktur
Das Produkt besteht aus mehreren Komponenten, im Grunde aus einem Server, Data-Collectoren for jede eingebundene LPAR und einer ISPF-basierten Benutzeroberfläche.
Der Server
Der XM4DB2 Server ist eine Started Task, die die Informationen der Data-Collectoren via TCP/IP empfängt und in XM4DB2s Datenbank speichert. Sobald ein Sammellauf eines Data-Collectors abgeschlossen ist, startet der Server die Auswertung. Wenn nötigt werden Alarmmeldungen an das zuständige Personal ausgegeben. In diesem Schritt führt der Server auch die vordefinierten Lösungsansätze aus. Der Server wird nur einmal installiert.
Der Data-Collector
Die Data-Collectoren sind Started Tasks, die das Gegenstück zum Server bilden. Ein Data-Collector überwacht alle gewählten DB2 Systeme auf seiner LPAR. Er kommuniziert via TCP/IP mit dem Server, das heißt er empfängt Anweisungen, sammelt und bereitet die Daten auf und schickt sie zurück zum Server.
Die Benutzeroberfläche
Die XM4DB2 Benutzeroberfläche basiert auf ISPF-Panels und besteht aus drei Teilen. Ein Teil, Exception Display genannt, stellt die gefundenen Exceptions dar. Ein weiterer Teil, genannt Administration, hilft bei der Parametrisierung von XM4DB2. Hier können Schwellwerte gesetzt und geändert werden und auch die Empfänger der Alarmmeldungen benannt werden. Außerdem können hier bestimmt Objekte von der Überwachung ausgeschlossen werden. Das ist sinnvoll, wenn diese Objekte aus einem bestimmten Grund bewusst nicht verfügbar sind. Den dritten Teil bildet die History. Hier werden alle Exceptions aufbewahrt, die je von XM4DB2 gefunden wurden. So lassen sich beispielsweise Ausfallzeiten von Objekten über bestimmt Zeiträume einsehen.
Datenfluss
Das Bild "Struktur und Datenfluss" hilft die Arbeitsweise von XM4DB2 besser zu verstehen.
- (1) In wählbaren Intervallen erwachen die Data-Collectoren und schicken eine Anfrage nach Parametern via TCP/IP zum XM4DB2 Server.
- (2) Der Server holt sich die Parameter aus der XM4DB2 Datenbank und
- (3) schickt sie dem anfragenden Data-Collector.
- (4) Der Data-Collector nutzt die Parameter um Analyseabfragen für jedes angegebene DB2 System zu erstellen.
- (5) Die Ergebnisse dieser Abfragen werden lokal gespeichert und
- (6) an Programmodule weitergegeben. Diese Module entfernen dann unbrauchbare Informationen und erstellen SQL-Inserts für die Datenbank.
- (7) Diese Statements werden dann an den Server geschickt.
- (8) Der Server für die Statements dann auf der Datenbank aus.
- (9) Der Server startet die Analyse der gesammelten Daten und aktualisiert die ALERT-Tabelle. Diese enthält nur offene Exceptions, das heißt, wird eine offene Exception nicht neu erkannt, wird sie aus dieser Tabelle entfernt. Neue Exceptions werden eingefügt. Es gibt auch eine History-Tabelle, die die Exceptions enthält, die seit der Installation auftraten.
- (10) Die ALERT-Tabelle bildet die Basis für die Email- und Reparaturfunktionen.
- (11) Die History-Tabelle enthält ein Ereignisprotokoll.
Überwachte Exceptions
Eingeschränkte Zustände
XM4DB2 erkennt Tablespaces in eingeschränkten Zuständen. Eingeschränkte Zustände sind nicht immer ein Problem. Der Status "RECP" (Recovery Pending) wird gesetzt, wenn ein Tablespace geladen wird. Er wird zum Problem, wenn das ladende Utility abbricht und der Status nicht wieder zurück gesetzt wird. Dann muss die Datenbank-Administration eingreifen. Andere Zustände dagegen sind immer ein Problem, "LPL" "Einträge in der Logical Page List" zum Beispiel. XM4DB2 kann zwischen kritischen und unkritischen Zuständen unterscheiden. Der Benutzer kann wählen, welche Zustände für ihn kritisch sind und überwacht werden sollen und welche nicht.
Utilities
Von Zeit zu Zeit werden Tablespaces von Utilities bearbeitet, LOAD und REORG sind nur zwei von ihnen. Bricht ein Utility ab, ist der Tablespace nicht mehr verfügbar. Die Administration muss hier eingreifen. XM4DB2 erkennt und zeigt abgebrochene Utilities an und erzeugt Alarmmeldungen. Das Programm erkennt auch die dazugehörigen Tablespaces. So meldet das Programm die abgebrochenen Utilities und deren Auswirkung und nicht mehr verfügbaren Ressourcen.
Volle Tablespaces - Füllstände und Extents
Es gibt Einschränkungen seitens DB2 und seitens z/OS, die die Größe eines Tablespaces begrenzen. Ein Tablespace CREATE gibt eine primäre Belegung und eine sekundäre Erweiterung an. Wann immer nötig, legt z/OS eine Erweiterung an. Abhängig von der z/OS Version gibt es eine maximale Anzahl möglicher Extents. XM4DB2 warnt, wenn sich die Größe dem Maximum annähert. Aus Leistungsgründen ist es nicht empfohlen mehr als 50 Extents zu erstellen. Daher ist es besser den Schwellwert in XM4DB2 auf 50 zu setzen.
Die maximale Größe hängt aber auch von DB2 ab. Abhängig vom Typ beschränkt DB2 die maximale Größe auf 2, 4, 8, 16, 32 oder 64 Gigabyte. Daher kann DB2 einen Tablespace als voll deklarieren, bevor die maximale Anzahl von Extents erreicht wird. Die Größe hängt auch von den Angaben des Benutzers für die primäre und sekundäre Allokation ab. Es besteht immer das Risiko einen Tablespace zu klein anzulegen, da die zukünftige Datenmenge schwer abgeschätzt werden kann. Das ist kritisch, da der Tablespace dann irgendwann die ankommenden Daten nicht mehr aufnehmen kann. In diesem Fall wird er Tablespace in einen eingeschränkten Zustand versetzt und ist nicht mehr verfügbar. Es gibt also eine Reihe von Einschränkungen für die Größe. XM4DB2 "kennt" diese Einschränkungen, prüft diese und gibt Alarmmeldungen aus. Die aktuelle Größe wird auch mit den benutzerdefinierten Schwellwerten abgeglichen. So kann der Benutzer selbst wählen, wann er benachrichtigt werden will.
Pläne und Packages
XM4DB2 findet Pläne und Packages, die zu einem Tablespace mit Exceptions gehören. So kann der Benutzer sehen, welche Pläne und Packages von einer Exception mit betroffen sind.
Prozeduren
Für den DB2 Work-Load-Manager kann man die Anzahl der Prozeduren angeben, die parallel laufen darf. Dieser Wert kann nicht beliebig hoch gesetzt werden, um zu vermeiden, dass Prozeduren das System blockieren. Prozeduren die nicht sofort ausgeführt werden können, werden in einer Warteschlange gehalten und werden nach einander ausgeführt. Prozeduren können abbrechen, wenn Ressourcen nicht verfügbar sind, oder sie einen Timeout erhalten. Wurde eine Prozedure wegen einer nicht verfügbaren Ressource gestoppt, so betrifft dies auch alle anderen Prozeduren in der Warteschlange, da diese auch versuchen werden auf diese Ressource zuzugreifen. Ein Timeout bedeutet ebenfalls eine Exception, da die Prozeduren nicht in der gegebenen Zeit abgearbeitet werden können. Das kann passieren, wenn das System ausgebremst wird. Die folgenden Prozeduren bekommen dann ebenfalls einen Timeout. Somit werden mehr und mehr Prozeduren in die Warteschlange aufgenommen. Es kann außerdem passieren, dass das System gar keine Prozeduren mehr ausführt, wenn eine abbricht. XM4DB2 verschickt Alarmmeldungen, wenn eine Prozedur einen Timeout erhält oder die Warteschlange zu groß wird und einen Schwellwert überschreitet und gleichzeitig mindestens eine Prozedur abgebrochen wurde. Der Schwellwert kann in der Benutzeroberfläche gesetzt werden.
