Release 2 des IBM-Datenbanksystems DB2 wird nach Herstellerangaben über eine dokumentierte Performance-Schnittstelle verfügen. In den USA ist es daraufhin bereits zur Ankündigung neuer Performance-Monitoren gekommen. Angesichts des wachsenden Wettbewerbs schildert Karl Vollmer die momentane Situation in diesem Marktsegment.
Seit DB2 auf dem Markt ist, mithin seit einigen Jahren, gab es eine Nachfrage nach einem Performance-Monitor, der speziell für das IBM-Produkt ausgelegt ist. Durch einen guten MVS-Monitor ist der Anwender zwar in der Lage, das Verhalten der "Black Box" DB2 zu messen, was CPU-Verbrauch, Ein-/Ausgabe-Verhalten und Paging betrifft; er kann aber nicht in DB2 unmittelbar hineinschauen und die Ursachen, beispielsweise für einen erhöhten CPU-Verbrauch, erkennen.
MVS-Monitor reicht nicht aus
DB2 schreibt auf Verlangen des Benutzers bestimmte SMF-Records, die mehr oder weniger detaillierte Informationen darüber enthalten, was sich innerhalb des DBMS-Produkts abgespielt hat. Diese DB2-spezifischen SMF-Records können dann aus den übrigen Records selektiert und nachfolgend ausgewertet werden.
Sehr bald machten sich die Entwickler daran, diese Informationsquelle auszuwerten. Die IBM hat bei der Esso AG in Hamburg, die in Deutschland eine Vorreiterrolle in Sachen DB2 spielt, ein Programm dazu entwickelt. Einige frühe Exemplare dieses Programms wurden auch über die IBM-User-Organisation "Guide" an andere Firmen verteilt.
Rechenzentren, die die SAS-Software benutzten, bekamen von dem Softwarehersteller die Record-Layouts der SMF-Records zur Verfügung gestellt und waren dann leicht selbst in der Lage, solche Auswerteprogramme zu schreiben. Darüber hinaus haben etliche DB2-Kunden auch entsprechende eigene Programme in Assembler geschrieben.
Alle diese Auswertungen hatten zwei prinzipielle Nachteile. Zum einen waren viele Datenfelder in den von DB2 geschriebenen SMF-Records nicht exakt definiert, so daß man bis heute nicht sicher ist, was bestimmte Inhalte bedeuten. Zum anderen waren solche Auswertungen systembedingt nie online. Bis die DB2-spezifischen SMF-Records aus den übrigen extrahiert und ausgewertet waren, hatte sich auch das hartnäckigste Datenbank-Problem längst erledigt.
Auswertungsprogramme sind viel zu langsam
Das schon erwähnte, von der IBM entwickelte Programm hat sich mittlerweile zu einem echten Produkt mit Namen DB2PM weiterentwickelt und eignet sich gut für querschnittliche Auswertungen. Mit ihm können Fragen beantwortet werden wie: Welche Aktivitäten waren gestern Nachmittag zwischen 14 Uhr und 15 Uhr auf dem DB2-System, und welche Maschinen-Ressourcen haben sich verbraucht?
Im April 1988 wurden dann die ersten beiden Online-Monitore für DB2 auf dem deutschen Markt vorgestellt: Insight/DB2 von Dbug, das in Deutschland von Plenum vertrieben wird, und Omegamon/DB2 von Candle. Beide Monitore unterstützen DB2 Release 1.3.
Mittlerweile hat IBM das Release 2 von DB2 vorgestellt, das im vierten Quartal 1988 allgemein verfügbar sein soll; und dieses neue Release bietet erstmals eine dokumentierte Performance-Schnittstelle. Also ist damit zu rechnen, daß im ersten und zweiten Quartal 1989 weitere Monitore auf dem Markt erscheinen, die sich auf diese Schnittstelle stützen.
Release 2 von DB2 hat dokumentierte Schnittstelle
Insight/DB2 und Omegamon/DB2 scheinen oberflächlich ähnlich, unterscheiden sich jedoch erheblich in der Art und Weise der Informationsgewinnung: Insight/DB2 aktiviert bei Bedarf einen oder mehrere der vielen Traces, die DB2 bietet, liest die von DB2 zur Verfügung gestellte Information und bereitet sie für den Bildschirm auf.
Omegamon/DB2 dagegen liest in den DB2-Kontrollblöcken mit. Beim Monitoren aus eigenen Adreßräumen wird im zu messenden System kein Overhead erzeugt; diese Methode ist inzwischen allgemeiner Stand der Technik.
Während Insight/DB2 nur unter TSO betrieben werden kann, bietet Omegamon/DB2 drei Betriebsarten: dediziert, unter VTAM und unter TSO. Auf diese Weise kann das DB2-System selbst dann noch beobachtet werden, wenn TSO schon blockiert ist, da VTAM im MVS üblicherweise eine höhere Priorität als ein TSO-Adreßraum hat. Im dedizierten Modus kann DB2 auch überwacht werden, wenn VTAM nicht zur Verfügung steht.
In der Handhabung werden ebenfalls unterschiedliche Wege beschritten. Bei beiden Monitoren erfolgt der Primäreinstieg über ein Menü. Danach werden bei Insight/DB2 sogenannte Dialoge aufgerufen. Der Anwender bekommt standardmäßig etliche vorgefertigte Dialoge und daneben eine Dokumentation über eine SQL-ähnliche Sprache, in der eigene Dialoge codiert werden können. Dabei ist der Zugriff auf eine größere Anzahl von Datenfeldern und Trace-Daten gewährleistet.
Das Candle-Produkt positioniert den Cursor auf das Ereignis, das näher interessiert. Wird dann die Zoom-Taste gedrückt, so sieht der Anwender im nächsten Schritt detaillierte Informationen. Dasselbe Verfahren kann solange angewendet werden, bis das System auf der untersten Dateiebene angelangt ist. Mit der PF-3-Taste kommt man wieder auf den vorherigen Bildschirm zurück, der dann die aktuelle, nicht die alte Information enthält.
Im DB2 werden sogenannte "Locks" gesetzt, um den Zugriff auf die Daten zu serialisieren. Mit Hilfe des "Lock-Trace" läßt sich herausfinden, welche Locks von welchem Thread gehalten werden und welcher andere Thread dadurch möglicherweise behindert wird.
Unterschiedliche Wege in der Handhabung
Dieses Trace wird von Insight/DB2 dynamisch aktiviert; das Manual warnt ausdrücklich davor, ihn ständig eingeschaltet zu lassen - wegen des damit verbundenen System-Overhead. Omegamon/DB2 hingegen stellt dieselbe Information ohne Trace zur Verfügung.
Beide Produkte haben die Möglichkeit, den jeweils aktiven SQL-Call anzuzeigen, egal ob er "Static" oder "Dynamic" ist. Auch hierzu benutzt Insight/DB2 einen DB2-Trace, was den Vorteil bietet, auch sehr schnell ablaufende SQL-Calls zu erfassen und für Hintergrundauswertungen abzuspeichern. Auf diese Weise kann sich der Benutzer alle SQL-Calls einer Anwendung anschauen. Diese Möglichkeit bietet Omegamon/DB2 nicht.
Insight/DB2 erfaßt schnelle SQL-Calls
Wenn es darum geht, mehrere DB2-Systeme zu überwachen, bieten beide Monitore die Möglichkeit, dynamisch umzuschalten. Insight/DB2 braucht für jedes zu messende DB2-System einen eigenen Adreßraum, in dem dann der entsprechende Programm-Code redundant vorhanden ist. Omegamon/DB2 mißt dagegen beliebig viele DB2-Systeme aus einem Adreßraum.
Bei der Überwachung der Exceptions, also der Ausnahmesituationen, hat Candle auf folgende Technik zurückgegriffen: Nachdem die Schwellwerte dynamisch oder statisch definiert sind, werden sie ständig überwacht. Durch Farb- beziehungsweise Helligkeitsänderung wird das Über- oder Unterschreiten selbst dann angezeigt, wenn der Benutzer sich gerade andere Meßwerte am Bildschirm ansieht. Er kann dann mittels der Zoom-Taste direkt auf das Ereignis umschalten oder sich über eine andere Taste eine mitgelieferte Empfehlung zur Problemlösung anzeigen lassen.
Anwender kann direkt zum Ereignis umschalten
Insight/DB2 bietet dagegen die Möglichkeit, sich diese Exceptions selbst mit Hilfe der schon erwähnten SQL-ähnlichen Sprache zu programmieren. Damit ist der Anwender in der Lage, theoretisch beliebig viele Schwellwerte zu definieren; überwachen kann er aber nur den, den er sich gerade anzeigen läßt. Wenn währenddessen ein anderer Wert über- oder unterschritten wird, geht diese Information jedoch nicht verloren; der Benutzer sieht das aber erst, wenn er sich diesen Schwellwert explizit auf den Schirm holt.
Will der Anwender eine generelle Übersicht über die Aktivitäten im DB2 haben, zeigen beide Systeme alle aktiven Threads an. Anhand der Correlation-ID läßt sich dann erkennen, ob dies beispielsweise ein CICS- oder ein TSO-Thread ist.
Omegamon/DB2 bietet darüber hinaus die Möglichkeit, sich nur CICS- beziehungsweise TSO-Threads anzuschauen; in diesem Fall ist die Correlation-ID nicht nötig, um zu unterscheiden, woher der Thread kommt.
Karl Vollmer ist bei der Candle GmbH, in München, in der Abteilung Technische Unterstützung beschäftigt.