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

application has decidedly higher Class 1 CPU and elapsed times as reported in DB2
Performance Expert.
Static read cursors
By manipulating the number of fetches from 50k to 10, but keeping the result set size the
same (1 million rows) you can see that the performance does not improve significantly (just
over 4% improvement). This is because the overhead for opening and formatting the
temporary table (class 3 suspend time) is essentially the same for both cases (4.29 vs. 4.40)
and populating it with 1 million rows to build the result set in both cases consumes the
majority of CPU cycles.
However, in the third case, you can see a dramatic reduction of class 2 elapsed and CPU time
when the qualified rows are changed from 1 million to 100k. In the static cursor case there are
data movement I/Os from the base table to the temporary table, so in this case class 2
elapsed and CPU time are dependent on the size of the temporary table to populate. Class 3
time also decreases as the temporary table size decreases.
As a conclusion, performance improvement for static scrollable cursors can be achieved, to a
certain extent, by writing SQL statements that limit the result set read into the temporary table
to only those rows that are essential.
Dynamic read cursors
See Table 3-4 again for the result trace record of the dynamic cursor case. Response times in
all three cases are dramatically improved when compared against the static cursor. The
elimination of formatting and building a result set into a temporary table when using the
dynamic cursor model accounts for this dramatic performance improvement. Thus, comparing
the static vs. dynamic cursor models, the DB2 class 2 elapsed times are:
► Fetch 50k / Result Set 1 M – 17.21 vs. 0.849 for 95% performance improvement
► Fetch 10 / Result Set 1 M – 16.75 vs. 0.069 for 99% performance improvement
► Fetch 50k / Result Set 100k – 5.61 vs. 0.849 for 85% performance improvement
The important thing here is that the amount of FETCHes becomes the deciding factor for the
dynamic cursor’s performance, whereas the number of qualifying rows was a deciding factor
in the static cursor model. When the number of FETCHes is changed from 50k to 10, the CPU
time is reduced from 0.849 to 0.069 for a 92% improvement. But the difference is not as large
as in the case of static cursor, when the number of qualified rows is changed.
Test scenario 2: Update cursor - Static vs. dynamic
This case tests positioned updates and deletes. The intent is to compare sensitive cursors for
static and dynamic.
As the sample program shows in Example 3-16, a static scrollable cursor is declared as
SENSITIVE STATIC and specified as FOR UPDATE. It means that the cursor works as a
cursor for a query to be used in positioned updates of the table. FETCH SENSITIVE is used
in the program, so in each FETCH, DB2 re-references the base table to pick up any
committed updates or deletes.
Example 3-16 Update program of static cursor
DECLARE C1 SENSITIVE STATIC SCROLL CURSOR WITH HOLD
FOR SELECT
COL1, COL2, COL3, COL4,
COL5,COL6 FROM TABLE
WHERE COL2 < ‘ROWNNNNNNNNN’
FOR UPDATE OF COL6;
100 DB2 UDB for z/OS Version 8 Performance Topics