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

► “NO” - Values in such columns may not be updated.
► “SAME” - Values in such columns may be updated if and only if the update leaves the row
belonging to the same partition.
5.6.6 Lock holder can inherit WLM priority from lock waiter
Assume that a transaction executes with a low WLM priority and makes updates to the
database. Because it is updating, it must acquire X-locks on the rows of the pages that it
modifies and then these X-locks are held until the transaction reaches a commit point. This is
business as usual. If such a transaction holds an X-lock on a row in which another transaction
is interested, the other transaction is forced to wait until the first transaction (with a low WLM
priority) commits. If the lock waiter performs very important work and is thus assigned a high
WLM priority, it would be desirable that it is not slowed down by other transactions that
execute in a low priority service class.
To reduce the time the high priority transaction has to wait for that lock to be given up by the
low priority transaction, it would be better if the waiting transaction could temporarily assign its
own priority to the transaction that holds the lock until this transaction frees the locked
resource.
DB2 V8 exploits WLM enqueue management. When a transaction has spent roughly half of
the lock timeout value waiting for a lock, then the WLM priority of the transaction, which holds
the lock, is increased to the priority of the lock waiter if the latter has a higher priority. If the
lock holding transaction completes, it resumes its original service class. In case multiple
transactions hold a common lock, this procedure is applied to all of these transactions.
This function is implemented by the PTF for APAR PK19303, currently open.
5.6.7 Detecting long readers
Prior to DB2 V8, DB2 issues warning messages DSNR035I and DSNJ031I for a long running
unit of recovery (UR) based on a number of system checkpoints taken since the beginning of
the UR or the number of log records written.
DB2 V8 takes this one step further by also alerting you when you have a long-running reader
in the system. It is probably less well known that not only updates have to commit frequently.
Also read-only transactions should commit regularly. This is to allow utilities (that need to
drain the object) to take control of the object, for example, during the switch phase of online
REORG, the utility needs full control of the object to switch between the shadow data set and
the actual data set used by DB2. For parallel operations, DB2 records this information only for
the originating task.
A new system parameter LONG-RUNNING READER THRESHOLD, LRDRTHLD, is provided
to specify the number of minutes that a read claim can be held by an agent before DB2 will
write an IFCID 313 record to report it as a long-running reader when statistics class 3 is
active.
IFCID 313 records all the LONG-RUNNING URs during a checkpoint or after exceeding the
LOG RECORD’s written threshold without commit or all the LONG-RUNNING readers after
exceeding the elapsed time threshold without commit.
5.6.8 Explain a stored procedure
This function allows you to run EXPLAIN without needing the authority to run the SQL to be
explained.
258 DB2 UDB for z/OS Version 8 Performance Topics