DB2 Version 9.7 for Linux, UNIX, and Windows
DB2 Version 9.7 for Linux, UNIX, and Windows
This parameter controls the generation of lock timeout events at the database level for the lock event monitor and affects all DB2® workload definitions.
If you set this parameter to NONE, no lock timeout events will be generated unless lock timeout event collection is enabled on DB2 Workload objects using the COLLECT LOCK TIMEOUT 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.
The mon_locktimeout parameter value represents a minimum level of collection that is enabled for all DB2 applications. The collection of lock timeout events can be enabled for a subset of DB2 applications using the COLLECT LOCK TIMEOUT DATA clause on a DB2 Workload object instead of the mon_locktimeout parameter. 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_locktimeout parameter is the only way for system applications to collect lock timeout data.
When you have two workloads, workload1 and workload2 and the database level configuration parameter is set to WITHOUT_HIST you can collect data for workload1 because the database level control specifies WITHOUT_HIST. If the parameter is set to NONE and HISTORY you can collect data for workload2 because the collect lock timeout data setting for workload2 is HISTORY.