Event type mappings to logical data groups

For file and pipe event monitors, event monitor output consists of an ordered series of logical data groupings. Regardless of the event monitor type, the output records always contain the same starting logical data groups. These frame the logical data groups whose presence varies depending on the event types recorded by the event monitor.

For file and pipe event monitors, event records may be generated for any connection and may therefore appear in mixed order in the stream. This means that you may get a transaction event for Connection 1, immediately followed by a connection event for Connection 2. However, records belonging to a single connection or a single event will appear in their logical order. For example, a statement record (end of statement) always precedes a transaction record (end of UOW), if any. Similarly, a deadlock event record always precedes the deadlocked connection event records for each connection involved in the deadlock. The application id or application handle (agent_id) can be used to match records with a connection.

Connection header events are normally written for each connection to the database. For deadlocks with details event monitors, they are only written when the deadlock occurs. In this case, connection header events are only written for participants in the deadlock and not for all connections to the database.

The logical data groupings are ordered according to four different levels: Monitor, Prolog, Contents, and Epilog. Following are detailed descriptions for each level, including the corresponding event types and logical data groups.


Information at the Monitor level is generated for all event monitors. It consists of event monitor metadata.
Table 1. Event Monitor Data Stream: Monitor Section
Event type Logical data group Available information
Monitor Level event_log_stream_header Identifies the version level and byte order of the event monitor. Applications can use this header to determine whether they can handle the evmon output stream.


The Prolog information is generated when the event monitor is activated.
Table 2. Event Monitor Data Stream: Prolog Section
Event type Logical data group Available information
Log Header event_log_header Characteristics of the trace, for example server type and memory layout.
Database Header event_db_header Database name, path and activation time.
Event Monitor Start event_start Time when the monitor was started or restarted.
Connection Header event_connheader One for each current connection, includes connection time and application name. Event connection headers are only generated for connection, statement, transaction, and deadlock event monitors. Deadlocks with details event monitors produce connection headers only when a deadlock occurs.


Information specific to the event monitor's specified event types is presented in the Contents section.

Table 3. Event Monitor Data Stream: Contents Section
Event type Logical data group Available information
Statement Event event_stmt Statement level data, including text for dynamic statements. Statement event monitors do not log fetches.
Subsection Event event_subsection Subsection level data.
Transaction Event1 event_xact Transaction level data.
Connection Event event_conn Connection level data.
Deadlock Event event_deadlock Deadlock level data.
Deadlocked Connection Event event_dlconn One for each connection involved in the deadlock, includes applications involved and locks in contention.
Deadlocked Connection Event with Details event_detailed_dlconn, lock One for each connection involved in the deadlock, includes applications involved, locks in contention, current statement information, and other locks held by the application contention.
Overflow event_overflow Number of records lost - generated when writer cannot keep up with a (non-blocked) event monitor.
Deadlocks with details history2 event_stmt_history List of statements executed in any unit of work that was involved in a deadlock.
Deadlocks with details history values2 event_data_value Parameter markers for a statement in the event_stmt_history list.
Activities event_activity List of activities that completed executing on the system or were captured before completion.
event_activitystmt Information about the statement the activity was executing if the activity type was a statement.
event_activityvals The data values used as input variables for each activity that is an SQL statement. These data values do not include LOB data, long data, or structured type data.
Statistics event_scmetrics Statistics computed from the activities that executed within each service class, work class, or workload in the system, as well as statistics computed from the threshold queues.
Threshold violations event_thresholdviolations Information identifying the threshold violated and the time of violation.
This option has been deprecated. Its use is no longer recommended and might be removed in a future release. Use the CREATE EVENT MONITOR FOR UNIT OF WORK statement to monitor transaction events.
This option has been deprecated. Its use is no longer recommended and might be removed in a future release. Use the CREATE EVENT MONITOR FOR LOCKING statement to monitor lock-related events, such as lock timeouts, lock waits, and deadlocks.


The Epilog information is generated during database deactivation (last application finished disconnecting):

Table 4. Event Monitor Data Stream: Epilog Section
Event type Logical data group Available information
Database Event event_db Database manager level data.
Buffer Pool Event event_bufferpool Buffer pool level data.
Table Space Event event_tablespace Table space level data.
Table Event event_table Table level data.