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

There is also no need to use RELEASE(DEALLOCATE) if you currently use this BIND
parameter to reduce XES contention.
8.3 Change to IMMEDWRITE default BIND option
8.3.1 Performance
Prior to V8, any remaining changed pages in a data sharing environment are written to the
group buffer pool during phase 2 of commit, unless otherwise specified by the IMMEDWRITE
BIND parameter. This enhancement changes the default processing to write changed pages
during commit phase 1. DB2 no longer writes changed pages to the coupling facility during
phase 2 of commit processing.
An implication of this change to commit processing is that DB2 V8 now charges all writes of
changed pages to the allied TCB, not the MSTR address space.
Consider the situation where one transaction updates DB2 data using INSERT, UPDATE, or
DELETE, and then, before completing phase 2 of commit, spawns a second transaction that
is executed on another DB2 member and is dependent on the updates that were made by the
first transaction. This type of relationship is referred to as “ordered dependency” between
transactions. In this case, the second transaction may not see the updates made by the first
transaction.
DB2 V5 introduced a new BIND parameter to overcome this problem. IMMEDWRITE(YES)
allows the user to specify that DB2 should immediately write updated GBP dependent buffers
to the coupling facility instead of waiting until commit or rollback. This option solves the
application issue at the expense of performance since it forces each individual changed page
immediately to the CF, ahead of commit, with each immediate write implying also a write to
the DB2 log, for as many changes are made to same page.
DB2 V6 extended this functionality. IMMEDWRITE(PH1) allows the user to specify that for a
given plan or package updated group buffer pool dependent pages should be written to the
coupling facility at or before phase 1 of commit. This option does not cause a performance
penalty. If the transaction subsequently rolls back, the pages will be updated again during the
rollback process and will be written again to the coupling facility at the end of abort.
In prior versions of DB2, changed pages in a data sharing environment are normally written
during phase 2 of the commit process, unless otherwise specified by the IMMEDWRITE BIND
parameter, or IMMEDWRI DSNZPARM parameter.
DB2 V8 changes the default processing to write changed pages during phase 1 of commit
processing. The options you can specify for the IMMEDWRITE BIND parameter remain
unchanged. However, whether you specify “NO”' or “PH1”, the behavior will be identical,
changed pages are written during phase 1 of commit processing.
In DB2 V8, changed pages are only written at or before phase 1, never at phase 2 of the
commit processing.
The book DB2 for z/OS and OS/390 Version 7 Performance Topics, SG24-6129, documents a
study of the impact of writing pages to the group buffer pool during phase 2 of commit,
IMMEDWRITE(NO), compared to writing pages to the group buffer pool during phase 1 of
commit, IMMEDWRITE(PH1). The testing revealed the Internal Throughput Rates are very
close to each other; meaning writing pages to the group buffer pool during phase 1 of commit
has little or no performance impact.
332 DB2 UDB for z/OS Version 8 Performance Topics