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

Req Out
(req / sec)
CHPID Busy
(%)
We can see from Table 8-8 that Protocol Level 2 generates a lot less XCF messaging traffic to
and from the coupling facility.
Table 8-9 shows extracts from RMF CF activity reports for the test workload.
Table 8-9 Protocol Level 2 - RMF CF Activity Report extract
Lock Structure
Activity
Total Requests
(/ sec)
Deferred Requests
(/ sec)
Contention
(/ sec)
False Contention
(/ sec)
CF Utilization
(%)
DB2 V7 DB2 V8
2,300 2,200 17 18
97.43 86.53 22.27 12.74
DB2 V7 DB2 V8
8,418.33 13,541.67
790.00 6.92
790.00 6.89
115.00 2.58
5.4 6.9
This table is rather interesting. It shows many more requests to the lock structure as a result
of using Protocol Level 2. This increase is in synchronous requests, as the number of
deferred or asynchronous requests have decreased.
Under DB2 V7, the IX L-locks are mapped to X-XES locks and therefore would occupy a lock
table entry in the lock structure. Once an XES essentially “owns” a lock table entry, by owning
the X-XES lock, that XES becomes the global lock manager for the lock table entry and has
the responsibility to resolve any contention that exists, (false, XES or real contention), for that
entry.
Once potential contention has been identified by two lock requests hashing to the same lock
table entry, the global lock manager XES must resolve the contention. The other XESs in the
group are instructed to send the lock information they have that pertains to the lock table
entry to the global lock manager XES so it can determine whether the contention is real or
false. Resolution is possible as each XES holds information about locks that its IRLM has
passed to it. Some optimization is in place so that once an XES “owns” a lock table entry,
other XESs in the group do not have to interact with the lock structure in the coupling facility.
Under DB2 V8 the IX L-locks are mapped to S-XES locks and do not occupy a lock table
entry. The end result is there will be fewer lock table entries “owned” by X-XES locks. The
good side is that this reduces XES contention (IX-L locks are now mapped to S-XES locks
which are compatible) and reduce false contention (S-XES locks do not “own” lock table
entries, so fewer lock table entries are occupied). The down side is that more lock requests
must be propagated to the coupling facility to determine if any contention may exist. The
majority of these requests are synchronous requests as contention does not exist (the
hashed lock table entry is not in use) and the request does not need to be suspended to
Chapter 8. Data sharing enhancements 329