DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 member already has the table space open for RW, global lock contention generally
occurs.
DB2 V8 attempts to reduce this global contention by remapping parent IX L-locks from XES-X
to XES-S locks. Data sharing locking performance benefits because parent IX and IS L-locks
are now both mapped to XES-S locks and are therefore compatible and can now be granted
locally by XES. DB2 no longer needs to wait for global lock contention processing to
determine that a new parent IX or IS L-lock is compatible with existing parent IX or IS L-locks.
The majority of parent L-lock contention occurs when the table space is opened by at least
one DB2 member in RW:
► IS-IS: We want to execute some read-only SQL against a table space and there are some
other members who currently have some read-only SQL active against the same table
space.
► IS-IX: We want to execute some read-only SQL against a table space and there are some
other members who currently have some update SQL active against the same table
space.
► IX-IS: We want to execute some update SQL against a table space and there are some
other members who currently have some read-only SQL active against the same table
space.
► IX- IX: We want to execute some update SQL against a table space and there are some
other members who currently have some update SQL active against the same table
space.
Parent lock contention with parent S L-locks is less frequent than checking for contention with
parent IS and IX L-locks. Parent S L-locks are only acquired when DB2 is about to issue
read-only SQL against a table space opened for RO.
To ensure that parent IX L-locks remain incompatible with parent S L-locks, S table and table
space L-locks are remapped to XES-X locks. This means that additional global contention
processing will now be done to verify that an S L-lock is compatible with another S L-lock, but
this is a relatively rare case (executing read-only SQL against a table space, where at least
one other DB2 member has the table space open in RO and currently has some read-only
SQL active against the same table space).
Another impact of this change is that child L-locks are no longer propagated based on the
parent L-lock. Instead, child L-locks are propagated based on the held state of the table
space P-lock. If the table space P-lock is negotiated from X to SIX or IX, then child L-locks
must be propagated.
It may be that some child L-locks are acquired before the page set P-lock is obtained. In this
case child L-locks will automatically be propagated. This situation occurs because DB2
always acquires locks before accessing the data. In this case, DB2 acquires that L-lock before
opening the table space to read the data. It can also happen during DB2 restart.
An implication of this change is that child L-locks will be propagated for longer than they are
needed, however this should not be a concern. There will be a short period from the time
where there is no intersystem read/write interest until the table space becomes
non-GBP-dependent, that is, before the page set P-lock reverts to X. During this time, child
L-locks will be propagated unnecessarily.
It is now important that L-locks and P-locks are maintained at the same level of granularity.
Remember now that page set P-locks now determine when child L-locks must be propagated
to XES.
326 DB2 UDB for z/OS Version 8 Performance Topics