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

► IBM z900 Series 2064 2-way processor
► ESS 800 DASD (with FICON channel)
Performance measurement results
In these measurements DB2 V8 is acting as a DRDA application server, accessed by another
DB2 V8 acting as a DRDA application requestor. We fetch 100,000 20 column rows from a
cursor without and with rowset positioning. The size of one row is 100 bytes.
We look at three cases: using multi-row fetch implicitly, explicitly and insert.
The results for implicit multi-row are presented in Figure 7-2. Note that the impact of multi-row
fetch depends on network performance, the number of columns and rows fetched in one fetch
request, the row size and the complexity of the SQL call. This means that your results are
likely to differ from what is presented here.
The requestor class 1 elapsed time is derived from requestor (class 2 elapsed time + (class 1
CPU time - class 2 CPU time)) in order to avoid wide fluctuation reported in accounting class
1 elapsed time.
(Sec)
9
6
3
0
5.7
Multi-row Fetch, Distributed - Host to Host
(Total rows fetched : 100,000 rows)
Requester Class 1 elapsed time
5.4
10.3
V8 default = V8 without explicit multi-row FETCH
V8 n1 x n2 = V8 with explicit multi-row FETCH
n1= # of FETCH
n2= # of rows per MR FETCH
Figure 7-2 Multi-row FETCH - Distributed host to host
4
3.4 3.2
v7 v8 10k 1k 100 10 (n1)
default 10 100 1K 10K (n2)
Note is that in the case of implicit multi-row fetch, the requestor application does not need to
be changed.
In DB2 V8 implicit multi-row FETCH (default), the results listed in Table 7-2 show a 5%
elapsed time improvement at the requestor and a 47% CPU time improvement at the server
(Sec)
2
1
0
Server Class 1 CPU time
1.76
0.93
2.01
1.13 1.03 1
v7 v8 10k 1k 100 10 (n1)
default 10 100 1K 10K (n2)
Chapter 7. Networking and e-business 287