The package cache event monitor captures data related to statement entries that have been flushed from the database package cache. This event monitor provides the history of the contents of the package cache which can help with SQL query performance and problem determination issues.
The package cache event monitor collects the same information as the MON_GET_PKG_CACHE_STMT table function, including the full set of available activity metrics and the executable section information of an entry.
Same information collected as the MON_GET_PKG_CACHE_STMT table function, as well as the full set of available activity metrics
Collects the same information gathered with the COLLECT BASE DATA clause and includes the executable section of the entry
When you need to investigate the individual execution of an SQL statement, you can use the MON_GET_PKG_CACHE_STMT table function (if the entries are still in the package cache) to compare the behavior of a cached entry relative to others. The execution metrics, compilation environment, and detailed descriptions for a cached entry are available for diagnostic purposes.
If an entry has already been flushed from the package cache, you can use the package cache event monitor to review the history of the cached entries which were flushed from the package cache. The history data contains the same information that the MON_GET_PKG_CACHE_STMT table function provides. In addition, the event monitor also provides the executable section of the statement. All of this applies to both dynamic and static SQL statements.
To create the package cache event monitor and collect package cache event monitor data, you must have DBADM or SQLADM authority.
The package cache event monitor only has the unformatted event table as the output option.
Before you create a package cache event monitor, identify the table space where you plan to store the unformatted event table for your event monitor. The recommended practice is to have a table space dedicated and configured to store the unformatted event table associated with any event monitor. Create the package cache event monitor in a tablespace with at least 8K pagesize to ensure that the event data is contained within the inlined BLOB column of the unformatted event table. If the BLOB column is not inlined, then the performance of writing and reading the events to the unformatted event table might not be efficient.
The database manager attempts to inline the event_data BLOB column in the unformatted event table, but this is not always possible. To check that the rows in the unformatted event table have been inlined, use the ADMIN_IS_INLINED function. If the rows have not been inlined, use the ADMIN_EST_INLINE_LENGTH functions to determine how much space the rows need.
Your other options, when you create an event monitor, are to specify any existing table space or to not specify any and have one chosen by default.
CREATE EVENT MONITOR MY_PKGCACHE_EVMON
FOR PACKAGE CACHE
WRITE TO UNFORMATTED EVENT TABLE (IN MY_EVMON_TABLESPACE)
To enable data collection, you must activate the event monitor using the SET EVENT MONITOR STATE statement. The package cache event monitor is not passive; following activation, it automatically starts collecting data whenever a statement is flushed from the package cache and meets the filter criteria set at the time of creation of the package cache event monitor.
The schema file ~/sqllib/misc/DB2EvmonPkgCache.xsd is used to document the expected output of the package cache event monitor report in an XML document. The schema file will reference a common monitor schema file (DB2MonCommon.xsd) to avoid duplicating the common contents.
An XML stylesheet is provided in ~/sqllib/samples/jdbc/DB2EvmonPkgCache.xsl.
Use these table functions to specify the data to extract using a SELECT statement. You have full control over selection, ordering, and other aspects provided by the SELECT statement.
java db2evmonfmt -d SAMPLE -ue SAMPLE_PKGCACHE_EVENTS -ftext -ss DB2EvmonPkgCache.xsl -hours 24