Selbstbeschreibender Datenstrom für Ereignismonitor

Ein Ereignismonitor, der Daten in eine Pipe oder eine Datei schreibt, gibt einen binären Datenstrom aus logischen Datengruppierungen aus, die für Pipe- und Dateiereignismonitore identisch sind. Sie können den Datenstrom mithilfe des Befehls db2evmon oder durch die Entwicklung einer Client-Anwendung formatieren. Dieser Datenstrom wird in einem selbstbeschreibenden Format dargestellt.
Abbildung 1 zeigt die Struktur des Datenstroms und Tabelle 1 enthält einige Beispiele für die logischen Datengruppen und Monitorelemente, die zurückgegeben werden könnten.
Hinweis : In den Beispielen und Tabellen werden beschreibende Namen für die Bezeichner verwendet. Im tatsächlichen Datenstrom steht vor diesen Namen das Präfix SQLM_ELM_. Für db_event beispielsweise würde in der Ereignismonitorausgabe SQLM_ELM_DB_EVENT angezeigt werden. Vor Typen steht im tatsächlichen Datenstrom das Präfix SQLM_TYPE_. Für 'header' beispielsweise würde im Datenstrom SQLM_TYPE_HEADER angezeigt werden.
Abb. 1. Datenstrom für Pipe- oder Dateiereignismonitor
Selbstbeschreibender Datenstrom für Ereignismonitor
  1. Die Struktur von 'sqlm_event_log_data_stream_header' unterscheidet sich von der Struktur anderer Header im Datenstrom. Der Wert im Feld 'version' legt fest, ob die Ausgabe als selbstbeschreibender Datenstrom verarbeitet werden kann.
    Dieser Header weist die gleiche Größe und den gleichen Typ auf wie Datenströme von Ereignismonitoren von vor Version 6. Dadurch können Anwendungen feststellen, ob die Ausgabe eines Ereignismonitors selbstbeschreibend ist oder im statischen Format von vor Version 6 vorliegen.
    Hinweis : Dieses Monitorelement wird durch Lesen von sizeof(sqlm_event_log_data_stream) Bytes aus dem Datenstrom extrahiert.
  2. Jede logische Datengruppe beginnt mit einem Header (Kopfdaten), der Größe und Elementname der Gruppe angibt. Dies gilt nicht für 'event_log_stream_header', da das Element 'size' dieser Gruppe einen Dummy-Wert zur Erhaltung der Abwärtskompatibilität enthält.
  3. Das Element 'size' im Header gibt die Größe aller Daten in der betreffenden logischen Datengruppe an.
  4. Die Informationen des Monitorelements folgen auf den Header der logischen Datengruppe und sind ebenfalls selbstbeschreibend.

Tabelle 1. Beispieldatenstrom eines Ereignismonitors
Logische Datengruppe Datenstrom Beschreibung
event_log_stream_header ┬►sqlm_little_endian Nicht verwendet (für Kompatibilität mit Vorgängerreleases).
├►200 Nicht verwendet (für Kompatibilität mit Vorgängerreleases).
└►sqlm_dbmon_version9 Version des Datenbankmanagers, der die Daten zurückgab. Ereignismonitore schreiben Daten im selbstbeschreibenden Format.
log_header_event ┬►100 Größe der logischen Datengruppe.
├►header Gibt den Start einer logischen Datengruppe an.
├►log_header Name der logischen Datengruppe.
─►4 Größe der in diesem Monitorelement gespeicherten Daten.
├►u32bit Monitorelementtyp - numerischer 32 Bit-Wert ohne Vorzeichen.
├►byte_order Name des erfassten Monitorelements.
└►little_endian Erfasster Wert für dieses Element.
┬►2 Größe der in diesem Monitorelement gespeicherten Daten.
  ├►u16bit Monitorelementtyp - numerischer 16 Bit-Wert ohne Vorzeichen.
  ├►codepage_id Name des erfassten Monitorelements.
  └►850 Erfasster Wert für dieses Element.
db_event ┬►100 Größe der logischen Datengruppe.
├►header Gibt den Start einer logischen Datengruppe an.
├►db_event Name der logischen Datengruppe.
─►4 Größe der in diesem Monitorelement gespeicherten Daten.
  ├►u32bit Monitorelementtyp - numerischer 32 Bit-Wert ohne Vorzeichen.
  ├►lock_waits Name des erfassten Monitorelements.
  └►2 Erfasster Wert für dieses Element.

Die logische Datengruppe 'event_log_stream_header' gibt die Version des Datenbankmanagers an, der die Daten zurückgegeben hat. Ereignismonitore schreiben Daten im selbstbeschreibenden Format. Ein Ereignismonitor hat im Gegensatz zu Snapshot Monitor kein Element size, das die Gesamtgröße des Trace zurückgibt. Der in 'event_log_stream_header' angegebene Wert ist ein Dummy-Wert, der nur zwecks Abwärtskompatibilität vorhanden ist. Die Gesamtgröße eines Ereignistrace ist nicht bekannt, wenn 'event_log_stream_header' geschrieben wird. Ein Ereignismonitortrace wird normalerweise so lange gelesen, bis das Ende einer Datei oder Pipe erreicht wird.

Der Protokollheader beschreibt die Merkmale des Trace und enthält Informationen wie beispielsweise das Speichermodell (z. B. Little Endian) des Servers, auf dem der Trace erfasst wurde, und die Codepage der Datenbank. Möglicherweise müssen Sie numerische Werte byteweise vertauschen, wenn das System, auf dem Sie die Ablaufverfolgung lesen, ein anderes Speichermodell als der Server hat (z. B. wenn Sie eine Ablaufverfolgung von einem UNIX-Server auf einem Windows 2000-System lesen). Außerdem ist unter Umständen eine Codepagekonvertierung erforderlich, wenn die Datenbank in einer anderen Sprache konfiguriert ist als die Maschine, von der aus der Trace gelesen wird. Beim Lesen des Trace kann das Element size verwendet werden, um eine logische Datengruppe im Trace zu überspringen.