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

Static updatable cursor
You can see that, for the static cursor model, the performance characteristics are the same as
for the read programs. SENSITIVE FETCHes with the static cursor refer to the base table.
Buffer pool I/O to the data in the base table occurs in each FETCH. The change of the
number of UPDATEs or DELETEs does not impact performance much when you compare the
first two cases, both building a temporary table of 1 million rows. In the second case, where
the SQL activity is reduced by a factor of 100, the performance improvement is only 2.9% for
class 2 CPU time, and 4% for class 2 elapsed time. Additional CPU time in accounting is
consumed by extracting the qualified rows and inserting them into the temporary table.
On the other hand, when the size of the temporary table is drastically reduced, but keeping
the SQL activity constant, you can see a significant performance improvement: A DB2 class 2
CPU time improvement of 88.5% and a DB2 class 2 elapsed time improvement of 70%.
Dynamic updatable cursor
The same characteristics as dynamic read cursor apply for the dynamic update cursor model.
When we compare Case 2 where we are only updating 10 rows and deleting 10 other rows
and compare that with Case 1 where we are updating and deleting 1,000 rows each, the class
2 DB2 CPU time shows a 89% improvement and the class 2 DB2 elapsed time exhibits a
63.7% improvement. On the other hand, when we keep the SQL activity the same (Case 1 vs.
Case 3) and vary the size of the result set, the class 2 DB2 CPU time only shows a 3%
performance improvement, and the class 2 DB2 elapsed time (0.589 vs. 0.496) shows a
15.7% improvement. Dynamic updatable cursor performance is greatly dependent on the
amount of SQL activity.
Comparing static updatable cursors to dynamic updatable cursors using class 2 DB2 elapsed
times for the metric, you see:
► UPDATE or DELETE 1k, result set 1 million – 16.43 vs. 0.589 for 96% performance
improvement
► UPDATE or DELETE 10, result set 1 million – 15.75 vs. 0.215 for 99% performance
improvement
► UPDATE or DELETE 1k, result set 50k – 4.93 vs. 0.496 for 90% performance
improvement
Test scenario 3: Multi-row processing with scrollable cursors
DB2 V8 introduces multiple-row processing for both the FETCH and INSERT statements.
Fetching multiple rows of data with one SQL statement can be done with both scrollable
(static and dynamic) and non-scrollable cursors. This enhancement helps to lower the SQL
statement execution cost by reducing the number of trips between the application and
database engine, and in a distributed environment reducing the number of send and receive
network messages as well.
Since the same performance principles apply regarding the size of the temporary table in the
static cursor model and the size of the result set in the dynamic model, regardless of the
single fetch or multi-fetch implementation, we only consider a temporary table size of 1 M for
the static cursor model and a result set size of 1 M for the dynamic cursor model in the
following two test cases.
We have discussed multi-row performance in 3.1, “Multi-row FETCH, INSERT, cursor
UPDATE and DELETE” on page 31. So in this chapter we only describe the performance of
multi-row FETCH and INSERT used in conjunction with static and dynamic scrollable cursor.
102 DB2 UDB for z/OS Version 8 Performance Topics