Event monitor self-describing data stream

An event monitor that writes to a pipe or file produces a binary stream of logical data groupings that are identical for both pipe and file event monitors. You can format the data stream by using the db2evmon command or by developing a client application. This data stream is presented in a self-describing format.
Figure 1 shows the structure of the data stream and Table 1 provides some examples of the logical data groups and monitor elements that could be returned.
Note: In the examples and tables descriptive names are used for the identifiers. These names are prefixed by SQLM_ELM_ in the actual data stream. For example, db_event would appear as SQLM_ELM_DB_EVENT in the event monitor output. Types are prefixed with SQLM_TYPE_ in the actual data stream. For example, headers appear as SQLM_TYPE_HEADER in the data stream.
Figure 1. Pipe or File Event Monitor Data Stream
Event monitor self-describing data stream
  1. The structure of the sqlm_event_log_data_stream_header is different than the other headers in the data stream. The version field determines if the output can be processed as a self-describing data stream.
    This header has the same size and type as pre-Version 6 event monitor streams. This allows applications to determine if the event monitor output is self-describing or is in the pre-Version 6 static format.
    Note: This monitor element is extracted by reading sizeof(sqlm_event_log_data_stream) bytes from the data stream.
  2. Each logical data group begins with a header that indicates its size and element name. This does not apply event_log_stream_header, as its size element contains a dummy value to maintain backwards compatibility.
  3. The size element in the header indicates the size of all the data in that logical data group.
  4. Monitor element information follows its logical data group header and is also self-describing.
Table 1. Sample event data stream
Logical Data Group Data Stream Description
event_log_stream_header ┬►sqlm_little_endian Not used (for compatibility with previous releases).
├►200 Not used (for compatibility with previous releases).
└►sqlm_dbmon_version9 The version of the database manager that returned the data. Event monitors write data in the self-describing format.
log_header_event ┬►100 Size of the logical data group.
├►header Indicates the start of a logical data group.
├►log_header Name of the logical data group.
├ ─►4 Size of the data stored in this monitor element.
│ ├►u32bit Monitor element type - 32 bit numeric.
│ ├►byte_order The name of the monitor element collected.
│ └►little_endian The collected value for this element.
└ ┬►2 Size of the data stored in this monitor element.
  ├►u16bit Monitor element type - unsigned 16 bit numeric.
  ├►codepage_id The name of the monitor element collected.
  └►850 The collected value for this element.
db_event ┬►100 Size of the logical data group.
├►header Indicates the start of a logical data group.
├►db_event Name of the logical data group.
└ ─►4 Size of the data stored in this monitor element
  ├►u32bit Monitor element type - unsigned 32 bit numeric.
  ├►lock_waits The name of the monitor element collected.
  └►2 The collected value for this element.

The event_log_stream_header identifies the version of the database manager that returned the data. Event monitors write their data in the self-describing format. An event monitor, unlike a snapshot monitor, does not have a size element that returns the total size of the trace. The number present in event_log_stream_header is a dummy value present for backwards compatibility. The total size of an event trace is not known when the event_log_stream_header is written. You typically read an event monitor trace until you reach an end of file or pipe.

The log header describes the characteristics of the trace, containing information such as the memory model (for example little endian) of the server where the trace was collected, and the code page of the database. You might have to do byte swapping on numeric values, if the system where you read the trace has a different memory model than the server (for example, if you are reading a trace from a UNIX server on a Windows 2000 system). Code page translation might also need to be done if the database is configured in a different language than the machine from which you read the trace. When reading the trace, you can use the size element to skip a logical data group in the trace.