Results 1 to 1 of 1
  1. #1
    Join Date
    May 2003

    Unanswered: More on DB2 Row Locks and Lock Escalation

    From an IBM article on DB2 Row Level Locking:

    “Now what happens if one application starts acquiring an unusually large number of locks and starts using up too much memory [that is used to store the locklist]. In this case, DB2 has an automatic (SMART) algorithm to reduce the [locklist] memory requirements on the system. The process is called lock escalation and should be an extremely infrequent event if a system has sufficient physical memory and is tuned appropriately. If the LOCKLIST memory area is full or if one application acquires "too many" locks then DB2 invokes a memory requirement reduction algorithm known as lock escalation.

    ‘Too many’ locks is defined by the DBA using a second configuration parameter called MAXLOCKS. MAXLOCKS defines the percentage of the LOCKLIST that any one application can acquire before a lock escalation will take place. By default MAXLOCKS is set to 22% of the LOCKLIST so by default if one application acquires more than 22% of the locklist, DB2 will escalate. When a lock escalation occurs, the application holding the most locks (and therefore using up the most memory) will convert its row level locks to a table level lock, thus reducing memory requirements on the system. As well this has the added advantage that the lock hogging application is no longer required to acquire row level locks for the table it already has locked and can therefore finish its work faster and get out of everyone else's way.”

    You can read the entire article (which compares Oracle and DB2 row level locking) at:

    However, as I noted in other posts, with multiple long running batch jobs running simultaneously, lock escalation can be a problem.
    Last edited by Marcus_A; 05-17-03 at 00:51.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts