DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 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 deadlock events are sent to any active locking event monitor when the deadlock event occurs. The data collected for the deadlock wait event will not include a history of activities executed by the application waiting on the deadlock.
If you set the parameter to HISTORY, the lock wait event will include a history of activities executed by the application waiting on the lock. The history only includes activities executed in the current transaction for the application and will only report the newest activities executed if the maximum sized is reached. The default history size is 250. The history size can be configured using the DB2_MAX_INACT_STMTS registry variable.
If you set the parameter value to HIST_AND_VALUES, activity history collected with the lock timeout event will include the input data values 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.