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

3.12.3 Performance
To describe the difference between CURRENTDATA(NO) and CURRENTDATA(YES), let us
give you an example:
1. Program A, bound with ISOLATION(CS) CURRENTDATA(YES), fetches a row from a
cursor. The row was read from the base table and not from a work file.
2. Program B tries to update the row just read by Program A. The access is not allowed
because the CURRENTDATA(YES) option for Program A caused a lock to be acquired on
the page or the row.
3. Program A issues a searched UPDATE of the row just fetched from step 1.
In this example you see that CURRENTDATA protects the integrity of the data read by
Program A between the fetch and the searched UPDATE.
If Program A were to be bound with CURRENTDATA(NO) then Program B would be able to
access the row just fetched by Program A (assuming correct timing and that lock avoidance
worked). When Program A issues its searched UPDATE, it can wipe out the changes just
made by Program B. So with the CURRENTDATA(NO) option, you must ensure the program
has read intent only, otherwise DB2 advantages of avoiding taking a lock to increase data
concurrency can be offset by data integrity issues.
Binding a plan or package with ISOLATION(CS) indicates that the data fetched by a cursor to
be committed, but if the application process returns to the same page, another application
might have since updated, deleted, or inserted qualifying rows. If the cursor is defined as
FOR UPDATE OF, the data returned by the cursor is stable and it may not be updated by
another transaction while the updateable cursor is positioned on it. If the cursor is defined as
read-only (or is ambiguous), then isolation level CS ensures that the data returned is
committed and the stability of the cursor is determined by the CURRENTDATA option.
If the application is bound with ISOLATION(RR) or ISOLATION(RS), the updates of the table
by other users are strictly restricted, you cannot acquire the advantage of using dynamic
scrollable cursors, since a row or page lock is held for all accessed rows at least until the next
commit point.
Several measurements, using different types of programs, have been implemented. There are
four scenarios. The first two cases deal with single-row processing. They compare static
scrollable cursors and dynamic scrollable cursors for FETCH and UPDATE programs. The
other two cases deal with multi-row processing. They compare single-row and multi-row
processing when using static or dynamic scrollable cursors for FETCH and UPDATE
programs.
Hardware and software environment
All the test cases use the following environment:
► Hardware: IBM z900 Series 2064-216 (z900 turbo)
– One LPAR with 2 dedicated processors
– 7 GB real storage
– Dedicated ESS model 800 (ESS)
– 4 dedicated FICON channels
► Software
– z/OS V1.4
– DB2 V8
– Non-data sharing
Chapter 3. SQL performance 97