DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
This parameter controls the generation of deadlock events at the database level for the lock event monitor.
If you set this parameter to NONE, no deadlock events will be generated unless deadlock event collection is enabled on DB2® Workload objects using the COLLECT DEADLOCK DATA clause.
If you set the parameter to WITHOUT_HIST, the data about lock events are sent to any active locking event monitor when the lock event occurs. The past activity history and input values are not sent to the event monitor.
If you set the parameter to HISTORY, you can collect the past activity history in the current unit of work for all of this type of lock events. The activity history buffer wraps after the maximum size limit is used. Meaning that the default limit on the number of past activities to be kept is 250. If the number of past activities is greater than the limit, only the newest activities are reported.
If you set the parameter value to HIST_AND_VALUES, the input data values are sent to any active locking event monitor for those activities that have them. These data values will not include LOB data, LONG VARCHAR data, LONG VARGRAPHIC data, structured type data, or XML data. For SQL statements compiled using the REOPT ALWAYS bind option, there will be no REOPT compilation or statement execution data values provided in the event information.
This parameter controls the collection deadlock events at the database level for the lock event monitor. The mon_deadlock parameter determines whether or not a deadlock wait event will be collected by the lock event monitor when a deadlock occurs.
The mon_deadlock parameter value represents a minimum level of collection that is enabled for all DB2 applications. When individual DB2 workloads specify a higher level of collection than the configuration parameter, the DB2 workload setting is used instead of the configuration parameter value. You should note that system applications do not run in a workload and so the mon_deadlock parameter is the only way for system applications to collect deadlock data.
To capture the deadlocks with the lock event monitor, as lock waiters or lock holders might span workloads, enable the deadlock collection at the database level. The level of data collected by a deadlock can be controlled individually at the workload level or can be set at the database level by this parameter.