Monday, April 22, 2013

DB2 Locking, Part 3: Locks Versus Latches


So far in this series on DB2 locking we have offered up a broad overview of what locking is and then delved into the world of table and table space locks. In this short entry, before we tackles page and row locks, we are going to look at the difference between a lock and a latch.

A true lock is handled by DB2 using the IRLM. The IRLM, or internal resource lock manager, is both a separate subsystem and an integral component of DB2. As its name implies, it manages locks for DB2.

However, whenever doing so is practical, DB2 can lock resources without going to the IRLM. This type of lock is called a latch. True locks are always set in the IRLM. Latches, by contrast, are set internally by DB2, without going to the IRLM.

When a latch is taken instead of a lock, it is handled in the Buffer Manager by internal DB2 code; so the cross-memory service calls to the IRLM are eliminated. Latches are usually held only briefly—for a shorter duration than locks. Also, a latch requires about one-third the number of instructions as a lock. Therefore, latches are more efficient than locks because they avoid the overhead associated with calling an external address space. Latches are used when a resource serialization situation is required for a short time. Both latches and locks guarantee data integrity. 

In subsequent blog entries, any usage of the term lock generically, refers to both locks and latches.

5 comments:

Sayee said...

Sir,

Could you explain how "we" can differentiate between locks and latches? I mean, how do we know when/if a lock/latch is taken? Also a real life example of resource serialization situation would be really helpful.

Craig S. Mullins said...

Maybe this will help. DB2 uses page (or row) locks managed by the IRLM to ensure and maintain user data concurrency. These locks are taken on behalf of applications requesting access to data. Latches are basically used to ensure page consistency. A latch on a page controls whether or not the control information on the page is currently being modified. Latching in this way can enable more efficient sequences of multiple changes (e.g. a program issuing multiple DELETEs).

Most performance monitors will enable you to track locks and latches. To get the appropriate information you will need to make sure that the proper traces and IFCIDs are started. Refer to the DSNWMSGS member IFCID details...

Craig S. Mullins said...

Another useful resource can be found here --> http://dbpedias.com/wiki/DB2_zOS:Monitoring_Locks_and_Latches

Ryan said...

Hi Craig..Could you please explain..exactly when a latch is acruired.. which stage? updating RIDS or somthing like that?

Craig S. Mullins said...

I'm not sure that all of the exact situations where DB2 incurs a latch are documented... at least, I do not recall seeing such a document.

Here is a nice presentation by John Campbell on Locks and Latches if you are interested http://public.dhe.ibm.com/software/dw/data/bestpractices/db2zos/DB2zBP_LocksandLatches_slides.pdf