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

3.12.5 Conclusion
Multi-row FETCH and UPDATE or DELETE with a dynamic cursor
We now apply the multi-row update and delete function to the updatable programs in the
dynamic cursor model. The results are shown in Table 3-9. They show a 17.8% performance
improvement in DB2 class 2 CPU time (0.135 vs. 0.111) and a 7% performance improvement
in DB2 class 2 elapsed time (0.589 vs. 0.547).
Table 3-9 Multi-row FETCH and UPDATE or DELETE dynamic
Multi-row update and delete with the dynamic cursor model result in significant performance
improvements over the static cursor model, but the multi-row fetch for update programs does
not improve as dramatically as the multi-row fetch for read-only programs. Compare them to
Table 3-7 on page 104. This is because with the read-only programs for multi-row fetch the
bulk of the DB2 CPU time is the reduction of the number of trips between the application and
database engine, which has been reduced by a factor of 100 (fetching 100 rows 500 times vs.
50,000 individual fetches). When we apply multi-row fetch to the update program, the DB2
CPU and elapsed times are not only accounting for the reduced number of trips between the
application and database engine for the fetches, but also the update (1,000 rows performed
25 rows at a time) and delete (1,000 rows also performed 25 rows at a time) activity. The
update and delete activity is performed on a rowset basis rather than individually, but it is a
significant consumer of CPU cycles due to its complexity.
For equivalent function, the dynamic cursor model generally outperforms the static cursor
model. The performance overhead to build the temporary table with static cursors is the
largest contributor of CPU overhead. For the dynamic cursor model, since all accesses are
performed on the base table, the amount of SQL activity (from a DB2 class 2 perspective)
becomes the deciding factor.
When multi-row processing is applied to static cursors (whether read or updatable), since the
temporary table is built row-by-row, regardless of the fetch implementation, this new feature
with DB2 V8 does not contribute significantly, at least with this amount of DML activity. But for
dynamic read cursors, multi-row fetch shows performance gains of 50% for both DB2 class 2
CPU and elapsed times over the single fetch equivalent program. While the dynamic
multi-row fetch and cursor update and delete program show significant improvement over its
single fetch, update and delete equivalent program (17.8% improvement in DB2 class 2 CPU
time), it is not as high as just the multi-row fetch program due to the intrinsically more complex
and costly functions of multi-row update and multi-row delete. In addition, the row set size for
the read-only multi-row fetch program was bigger (100 vs. 25) and resulted in less interaction
between the application and database engine.
3.12.6 Recommendations
With a static cursor, class 3 time is heavily dependent on the size of the temporary table for
both read and updates. So it is important for the performance of a static scrollable cursor to
106 DB2 UDB for z/OS Version 8 Performance Topics
Dynamic single row
UPDATE or
DELETE 1k each
Open 1M
Class 1 ET / CPU 0.601 / 0.148 0.582 / 0.115
Class 2 ET / CPU 0.589 / 0.135 0.547 / 0.111
Class 3 suspend 0.454 0.433
Dynamic multi-row
UPDATE or DELETE 25 rows
x 40 times each
Open 1M