Create Event Monitor Options

[ Team LiB ]

Create Event Monitor Options Options can be specified on the CREATE EVENT MONITOR statement to control the amount of information collected, to determine how the event monitor stops and starts, to specify the location and size of output files or pipes, types and size of buffers, and scope of the event monitor (local or global). We have already discussed the various types of event monitors that can be created. We will now focus on major event monitor options and associated details. WHERE event condition WHERE event condition is used to specify one of three possible event conditions as follows: APPL_ID� Specifies that the application ID of each connection should be compared with the comparison-string in order to determine if the connection should generate CONNECTION, STATEMENT, or TRANSACTION events, if specified. This option can also be used for specific AUTH_IDs or APPL_NAMES. The comparison-string is a character string that is compared with the APPL_ID, AUTH_ID, or APPL_NAME of each application that connects to the database. If the specific event condition is met, event data is captured. WRITE TO WRITE TO identifies the target output mechanism that will hold the event monitor data. An event monitor can write to a table, pipe, or file. I will briefly describe how DB2 event monitors write to files and pipes, and then go into much more detail using DB2 event monitors that write to the new event monitor WRITE TO TABLE capability in DB2 v8. When writing event monitors to a PIPE, the event monitor writes the data to the pipe in a single stream, as if it were a single, infinitely long file. When writing data to a pipe, an event monitor does not perform blocked writes. This is important because if there is no room in the pipe buffer, the event monitor will discard the data. The monitoring application using the pipe must read the data without delay to ensure no loss of data. NOTE It is uncommon for DBAs to use pipes for event monitors. This is because an application is required to read the data from a pipe; and the application must be started in advance of writing data to a pipe. However, it is common for ISV tools to use pipes, as they provide an application as part of the tool to read the pipe and process the data. Using a pipe is very efficient and incurs the lowest amount of overhead on the database. However, as indicated, an application is required to read and process the data. When writing event monitor data to a file (or set of files), the event data streams to files, which follow the following naming convention: 00000000.evt, 00000001.evt, 00000002.evt … nnnnnnn.evt unless limited by the MAXFILES option. Even though multiple files may be used, the data is treated as one logical file.

[ Team LiB ]