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

► Static SQL with table space scan
► Fetch, insert, fetch/update and fetch/delete, each for a total of 100k rows
– V7 and V8 single row
– V8 multi-row (explicit)
Multi-row fetch performance
Figure 3-4 shows the CPU time (class 1) measurement for single-row fetch and multi-row
fetch for all 100,000 rows from a non-partitioned table space. For the multi-row fetch cases we
fetch the 100k rows varying the rowset from 2, 10, 100, 1k, and 10k rows.
Class 1 CPU Time (Sec) 2-way 2084
1.5
1
0.5
0
1.09
Multi-row Fetch Performance
(100,000 rows Fetched / test)
Single-row V8 multi-row
1.15
Figure 3-4 CPU time (class 1) for single-row and multi-row fetch
1.02
V7 V8 50kx2 10kx10 1kx100 100x1k 10x10k
V8 with explicit multi-row Fetch
These measurements show:
► For single-row fetch there is a 5% increase in CPU time when we compare the
measurements in V7 to V8. This increase is primarily due to the overhead when operating
in 64-bit addressing as compared to 31-bit addressing and normal release to release
overhead.
► 40% CPU time improvement with MR=10 rows
► 50% CPU time improvement with MR=100+ rows
The performance improvement using multi-row fetch in general depends on:
► Number of rows fetched in one fetch
► Number of columns fetched (more improvement with fewer columns), data type and size of
the columns
0.64
50kx2 - 50,000 fetch loops, 2 rows per multi-row fetch
10kx10 - 10,000 fetch loops, 10 rows per multi-row fetch
1kx100 - 1,000 fetch loops, 100 rows per multi-row fetch
100x1k - 100 fetch loops, 1,000 rows per multi-row fetch
10x10k - 10 fetch loops, 10,000 rows per multi-row fetch
0.55
0.54
0.54
Chapter 3. SQL performance 35