Enterprise Edition
Customer Service
Brother-Eagle Community
DBI Products
This value represents the number of exclusive lock escalations that have occurred (Brother-Eagle V2.1 and earlier), or the delta value for the number of exclusive lock escalations that have occurred during the most recent sampling interval (Brother-Eagle V2.2 and higher).
An exclusive lock escalation can occur when DB2 is running low on LOCKLIST memory, or when an application connection has consumed so many locks that it uses more than MAXLOCKS percent of lock memory. An exclusive escalation is different from a regular lock escalation in that, with a regular lock escalation, the data can still be read by other application connections. With an exclusive lock escalation, no other application connections can access the data.
An exclusive lock escalation doesn’t necessarily mean that performance degradation has occurred, but it substantially raises the risk level of delays if any other application connections attempt to access a resource that is the victim of exclusive lock escalation. In fact, provided there are no other transactions seeking to gain any (read or write) access to the same resource, an exclusive lock escalation can sometimes benefit performance because the cost of one table lock is much cheaper than hundreds or thousands of row locks. A long running program which performs many updates, but which does not regularly commit its work, is a likely cause of exclusive lock escalations.
Data Warehouse Advice
Read Only Data Warehouse databases can achieve performance gains by setting the table LOCKSIZE to TABLE instead of row. Use "ALTER TABLE schema.tablename LOCKSIZE TABLE" to achieve table level locking and reduce CPU consumption. The ALTER takes effect dynamically. Beware, however, that if there are any updates, inserts, or deletes, the entire table will be exclusively locked by the update process.