SQL Reference
The CREATE EVENT MONITOR statement defines a monitor that will record
certain events that occur when using the database. The definition of
each event monitor also specifies where the database should record the
events.
Invocation
This statement can be embedded in an application program or issued
interactively. It is an executable statement that can be dynamically
prepared. However, if the bind option DYNAMICRULES BIND applies, the
statement cannot be dynamically prepared (SQLSTATE 42509).
Authorization
The privileges held by the authorization ID must include either SYSADM or
DBADM authority (SQLSTATE 42502).
Syntax
>>-CREATE--EVENT--MONITOR--event-monitor-name--FOR-------------->
.-,----------------------------------------------------------.
V |
>---------+-+-DATABASE----+-------------------------------------+--+>
| +-TABLES------+ |
| +-DEADLOCKS---+ |
| +-TABLESPACES-+ |
| '-BUFFERPOOLS-' |
'--+-CONNECTIONS--+---+-----------------------------+-'
+-STATEMENTS---+ '-WHERE--| Event Condition |--'
'-TRANSACTIONS-'
.-MANUALSTART--.
>----WRITE--TO--+-PIPE--pipe-name--------------------+---+--------------+>
'-FILE--path-name--| File Options |--' '-AUTOSTART----'
.-LOCAL--.
>-----+-----------------------+---+--------+-------------------><
'-ON NODE--node-number--' '-GLOBAL-'
Event Condition
.-AND | OR------------------------------------------------------------.
V |
|------+-----+--+--+-APPL_ID---+---+-=----------+---comparison-string--+--+->
'-NOT-' | +-AUTH_ID---+ | (1) | |
| '-APPL_NAME-' +-<>---------+ |
| +->----------+ |
| | (1) | |
| +->=---------+ |
| +-<----------+ |
| | (1) | |
| +-<=---------+ |
| +-LIKE-------+ |
| '-NOT--LIKE--' |
'-(Event Condition)------------------------------------'
>---------------------------------------------------------------|
File Options
|---+--------------------------------+-------------------------->
| .-NONE------------. |
'-MAXFILES--+-number-of-files-+--'
>-----+--------------------------+---+--------------------+----->
| .-pages--. | '-BUFFERSIZE--pages--'
'-MAXFILESIZE--+-NONE---+--'
.-BLOCKED----. .-APPEND--.
>-----+------------+---+---------+------------------------------|
'-NONBLOCKED-' '-REPLACE-'
Notes:
- Other forms of these operators are also supported. See Basic Predicate for more details.
Description
- event-monitor-name
- Names the event monitor. This is a one-part name. It is an
SQL identifier (either ordinary or delimited). The
event-monitor-name must not identify an event monitor that already
exists in the catalog (SQLSTATE 42710).
- FOR
- Introduces the type of event to record.
- DATABASE
- Specifies that the event monitor records a database event when the last
application disconnects from the database.
- TABLES
- Specifies that the event monitor records a table event for each active
table when the last application disconnects from the database. An
active table is a table that has changed since the first connection to the
database.
- DEADLOCKS
- Specifies that the event monitor records a deadlock event whenever a
deadlock occurs.
- TABLESPACES
- Specifies that the event monitor records a table space event for each
table space when the last application disconnects from the database.
- BUFFERPOOLS
- Specifies that the event monitor records a buffer pool event when the last
application disconnects from the database.
- CONNECTIONS
- Specifies that the event monitor records a connection event when an
application disconnects from the database.
- STATEMENTS
- Specifies that the event monitor records a statement event whenever a SQL
statement finishes executing.
- TRANSACTIONS
- Specifies that the event monitor records a transaction event whenever a
transaction completes (that is, whenever there is a commit or rollback
operation).
- WHERE event condition
- Defines a filter that determines which connections cause a CONNECTION,
STATEMENT or TRANSACTION event to occur. If the result of the event
condition is TRUE for a particular connection, then that connection will
generate the requested events.
This clause is a special form of the WHERE clause that should not be
confused with a standard search condition.
To determine if an application will generate events for a particular event
monitor, the WHERE clause is evaluated:
- For each active connection when an event monitor is first turned
on.
- Subsequently for each new connection to the database at connect
time.
The WHERE clause is not evaluated for each event.
If no WHERE clause is specified then all events of the specified event type
will be monitored.
- 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 (whichever was
specified).
- AUTH_ID
- Specifies that the authorization 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 (whichever was
specified).
- APPL_NAME
- Specifies that the application program name of each connection should be
compared with the comparison-string in order to determine if the
connection should generate CONNECTION, STATEMENT or TRANSACTION events
(whichever was specified).
The application program name is the first 20 bytes of the application
program file name, after the last path separator.
- comparison-string
- A string to be compared with the APPL_ID, AUTH_ID, or APPL_NAME of each
application that connects to the database. comparison-string
must be a string constant (that is, host variables and other string
expressions are not permitted).
- WRITE TO
- Introduces the target for the data.
- PIPE
- Specifies that the target for the event monitor data is a named
pipe. The event monitor writes the data to the pipe in a single stream
(that is, as if it were a single, infinitely long file). When writing
the data to a pipe, an event monitor does not perform blocked writes.
If there is no room in the pipe buffer, then the event monitor will discard
the data. It is the monitoring application's responsibility to
read the data promptly if it wishes to ensure no data loss.
- pipe-name
- The name of the pipe (FIFO on AIX) to which the event monitor will write
the data.
The naming rules for pipes are platform specific. On UNIX operating
systems pipe names are treated like file names. As a result, relative
pipe names are permitted, and are treated like relative path-names (see
path-name below). However, on OS/2, Windows 95 and Windows NT,
there is a special syntax for a pipe name. As a result, on OS/2,
Windows 95 and Windows NT absolute pipe names are required.
The existence of the pipe will not be checked at event monitor creation
time. It is the responsibility of the monitoring application to have
created and opened the pipe for reading at the time that the event monitor is
activated. If the pipe is not available at this time, then the event
monitor will turn itself off, and will log an error. (That is, if the
event monitor was activated at database start time as a result of the
AUTOSTART option, then the event monitor will log an error in the system error
log.) If the event monitor is activated via the SET EVENT MONITOR STATE
SQL statement, then that statement will fail (SQLSTATE 58030).
- FILE
- Indicates that the target for the event monitor data is a file (or set of
files). The event monitor writes out the stream of data as a series of
8 character numbered files, with the extension "evt". (for
example, 00000000.evt, 00000001.evt, and
00000002.evt). The data should be considered to be one logical
file even though the data is broken up into smaller pieces (that is, the start
of the data stream is the first byte in the file 00000000.evt; the
end of the data stream is the last byte in the file
nnnnnnnn.evt).
The maximum size of each file can be defined as well as the maximum number
of files. An event monitor will never split a single event record
across two files. However, an event monitor may write related records
in two different files. It is the responsibility of the application
that uses this data to keep track of such related information when processing
the event files.
- path-name
- The name of the directory in which the event monitor should write the
event files data. The path must be known at the server, however, the
path itself could reside on another partition or node (for example, in a
UNIX-based system, this might be an NFS mounted file). A string
constant must be used when specifying the path-name.
The directory does not have to exist at CREATE EVENT MONITOR time.
However, a check is made for the existence of the target path when the event
monitor is activated. At that time, if the target path does not exist,
an error (SQLSTATE 428A3) is raised.
If an absolute path (a path that starts with the root directory on AIX, or
a disk identifier on OS/2, Windows 95 and Windows NT) is specified, then the
specified path will be the one used. If a relative path (a path that
does not start with the root) is specified, then the path relative to the
DB2EVENT directory in the database directory will be used.
When a relative path is specified, the DB2EVENT directory is used to
convert it into an absolute path. Thereafter, no distinction is made
between absolute and relative paths. The absolute path is stored in the
SYSCAT.EVENTMONITORS catalog view.
It is possible to specify two or more event monitors that have the same
target path. However, once one of the event monitors has been activated
for the first time, and as long as the target directory is not empty, it will
be impossible to activate any of the other event monitors.
- File Options
- Specifies the options for the file format.
- MAXFILES NONE
- Specifies that there is no limit to the number of event files that the
event monitor will create. This is the default.
- MAXFILES number-of-files
- Specifies that there is a limit on the number of event monitor files that
will exist for a particular event monitor at any time. Whenever an
event monitor has to create another file, it will check to make sure that the
number of .evt files in the directory is less than
number-of-files. If this limit has already been reached, then
the event monitor will turn itself off.
If an application removes the event files from the directory after they
have been written, then the total number of files that an event monitor can
produce can exceed number-of-files. This option has been
provided to allow a user to guarantee that the event data will not consume
more than a specified amount of disk space.
- MAXFILESIZE pages
- Specifies that there is a limit to the size of each event monitor
file. Whenever an event monitor writes a new event record to a file, it
checks that the file will not grow to be greater than pages (in units
of 4K pages). If the resulting file would be too large, then the event
monitor switches to the next file. The default for this option
is:
- OS/2, Windows 95 and Windows NT - 200 4K pages
- UNIX - 1000 4K pages
The number of pages must be greater than at least the size of the event
buffer in pages. If this requirement is not met, then an error
(SQLSTATE 428A4) is raised.
- MAXFILESIZE NONE
- Specifies that there is no set limit on a file's size. If
MAXFILESIZE NONE is specified, then MAXFILES 1 must also be specified.
This option means that one file will contain all of the event data for a
particular event monitor. In this case the only event file will be
00000000.evt.
- BUFFERSIZE pages
- Specifies the size of the event monitor buffers (in units of 4K
pages). All event monitor file I/O is buffered to improve the
performance of the event monitors. The larger the buffers, the less I/O
will be performed by the event monitor. Highly active event monitors
should have larger buffers than relatively inactive event monitors.
When the monitor is started, two buffers of the specified size are
allocated. Event monitors use double buffering to permit asynchronous
I/O.
The minimum and default size of each buffer (if this option is not
specified) is 4 pages (that is, 2 buffers, each 16 K in size). The
maximum size of the buffers is limited by the size of the monitor heap
(MON_HEAP) since the buffers are allocated from the heap. If using a
lot of event monitors at the same time, increase the size of the MON_HEAP
database configuration parameter.
Event monitors that write their data to a pipe also have two internal
(non-configurable) buffers that are each 1 page in size. These buffers
are also allocated from the monitor heap (MON_HEAP). For each active
event monitor that has a pipe target, increase the size of the database heap
by 2 pages.
- BLOCKED
- Specifies that each agent that generates an event should wait for an event
buffer to be written out to disk if the agent determines that both event
buffers are full. BLOCKED should be selected to guarantee no event data
loss. This is the default option.
- NONBLOCKED
- Specifies that each agent that generates an event should not wait for the
event buffer to be written out to disk if the agent determines that both event
buffers are full. NONBLOCKED event monitors do not slow down database
operations to the extent of BLOCKED event monitors. However, NONBLOCKED
event monitors are subject to data loss on highly active systems.
- APPEND
- Specifies that if event data files already exist when the event monitor is
turned on, then the event monitor will append the new event data to the
existing stream of data files. When the event monitor is reactivated,
it will resume writing to the event files as if it had never been turned
off. APPEND is the default option.
The APPEND option does not apply at CREATE EVENT MONITOR time, if there is
existing event data in the directory where the newly created event monitor is
to write its event data.
- REPLACE
- Specifies that if event data files already exist when the event monitor is
turned on, then the event monitor will erase all of the event files and start
writing data to file 00000000.evt.
- MANUALSTART
- Specifies that the event monitor not be started automatically each time
the database is started. Event monitors with the MANUALSTART option
must be activated manually using the SET EVENT MONITOR STATE statement.
This is the default option.
- AUTOSTART
- Specifies that the event monitor be started automatically each time the
database is started.
- ON NODE
- Keyword that indicates that specific partitions are specified.
- node-number
- Specifies a partition number where the event monitor runs and write the
events. With the monitoring scope defined as GLOBAL, all partitions
report to the specified partition number. The I/O component will
physically run on the specified partition, writing its records to /tmp/dlocks
directory on that partition.
- GLOBAL
- Event monitor reports from all partitions. For a partitioned
database in DB2 Universal Database Version 7, only deadlock event monitors can
be defined as GLOBAL. The global event monitor will report deadlocks
for all nodes in the system.
- LOCAL
- Event monitor reports only on the partition that is running. It
gives a partial trace of the database activity. This is the
default.
Rules
- Each of the event types (DATABASE, TABLES, DEADLOCKs,...) can only be
specified once in a particular event monitor definition.
Notes
- Event monitor definitions are recorded in the SYSCAT.EVENTMONITORS
catalog view. The events themselves are recorded in the
SYSCAT.EVENTS catalog view.
- For detailed information on using the database monitor and on interpreting
data from pipes and files, see the System Monitor Guide and
Reference.
Examples
Example 1: The following example creates an event
monitor called SMITHPAY. This event monitor, will collect event data
for the database as well as for the SQL statements performed by the PAYROLL
application owned by the JSMITH authorization ID. The data will be
appended to the absolute path /home/jsmith/event/smithpay/. A maximum
of 25 files will be created. Each file will be a maximum of
1 024 4K pages long. The file I/O will be non-blocked.
CREATE EVENT MONITOR SMITHPAY
FOR DATABASE, STATEMENTS
WHERE APPL_NAME = 'PAYROLL' AND AUTH_ID = 'JSMITH'
WRITE TO FILE '/home/jsmith/event/smithpay'
MAXFILES 25
MAXFILESIZE 1024
NONBLOCKED
APPEND
Example 2: The following example creates an event
monitor called DEADLOCKS_EVTS. This event monitor will collect deadlock
events and will write them to the relative path DLOCKS. One file will
be written, and there is no maximum file size. Each time the event
monitor is activated, it will append the event data to the file
00000000.evt if it exists. The event monitor will be started
each time the database is started. The I/0 will be blocked by
default.
CREATE EVENT MONITOR DEADLOCK_EVTS
FOR DEADLOCKS
WRITE TO FILE 'DLOCKS'
MAXFILES 1
MAXFILESIZE NONE
AUTOSTART
Example 3: This example creates an event monitor
called DB_APPLS. This event monitor collects connection events, and
writes the data to the named pipe /home/jsmith/applpipe.
CREATE EVENT MONITOR DB_APPLS
FOR CONNECTIONS
WRITE TO PIPE '/home/jsmith/applpipe'
[ Top of Page | Previous Page | Next Page ]