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

an online transaction with very simple SQL statements each accessing and retrieving one
row, the overhead can be about 1% if there is no other transaction running. On the other
hand, if there are many concurrent transactions, we have heard of up to 15% overhead. A
20% figure is for a projected maximum number for 32-way complex with many concurrent
threads.
In DB2 V8, the overhead is thought to be completely negligible as there is no longer SMF 89
data collection for each SQL statement.
We therefore recommend you select SMF89 YES only if you use measured usage pricing.
4.13.4 Lock avoidance enhancements
We briefly describe the main lock avoidance enhancements.
Overflow lock avoidance
Sometimes when you update a variable length row, DB2 is not able to store the row on the
original page. This happens when the size of the row has increased and it no longer fits on its
original page. In order to avoid updating all the indexes that point to that row (each index entry
contains a RID, which contains the original page number), a pointer record is created on the
original page. The pointer record then points to the actual row. If a later update of the row
decreases its size, it can be put back into its original page, again without any updates to the
index.
You can have variable length rows when:
► Using variable length columns like VARCHAR and VARGRAPHIC
► Using DB2 data compression
► Altering a table to add a column, but you have not performed a REORG to materialize all
the rows to have the new column
► Using the new V8 online schema enhancements to enlarge the a columns data type, but
you have not run REORG to materialize all the rows to the latest format
The good thing about using the overflow pointer is that we avoid updating the indexes. The
disadvantage is that we potentially double the number of data I/Os and getpage requests, and
increase the number of lock and unlock requests. This can obviously impact performance.
You can check whether or not overflow records exist by looking at the FARINDREF and
NEARINDREF information in SYSIBM.SYSTABLEPART. This information is updated by
running RUNSTATS and provides information about the number of rows that have been
relocated far from (> 16 pages) or near (< 16 pages) their “home” page. We recommend you
run a REORG when (FARINDREF +NEARINDREF) exceed 5 to 10%. To reduce the amount
of overflow rows, and hence the number of double I/Os, getpages, and lock and unlock
requests, you can use a higher PCTFREE value (FREEPAGE does not help in this case).
In V7, there is no lock avoidance on both the pointer record and the overflow record itself.
With DB2 Version 8, only the pointer is locked.
Table 4-15 Lock avoidance of overflow record
Isolation Level Cursor Stability
with CURRENTDATA NO or YES
214 DB2 UDB for z/OS Version 8 Performance Topics
V7 V8
Lock and Unlock required for the pointer record YES YES
Lock and Unlock required for the overflow record YES NO