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

2.1.3 I/O time
2.1.4 Virtual storage
experienced. But this is not the main reason, since the developers have worked hard to keep
the same path length when executing the DB2 functions. The main reasons are that the
instructions now deal with possibly large variable length names and that 64-bit mode
instructions often take more time to execute than in 31-bit mode, and there is a need for a lot
of expansion of instructions from the 24 and 31-bit type.
DB2 V8 contains many new features in the areas of availability, scalability, and portability from
other platforms, such as family consistency, user productivity, and other features. For those
applications not taking advantage of DB2 V8 performance features, an increase in CPU time
is anticipated to support all of these new features.
As you examine the different measurements in this book reported in 4.1, “DB2 CPU
considerations” on page 129, you see that there is fluctuation in CPU cost depending on the
different types of workloads tested. The CPU ranges vary but generally the additional CPU
cost is between 0 and 10%. Of course, we think that eventually you make changes to your
applications and subsystem to take advantage of those new features that ultimately reduce
the CPU cost and hopefully result even in a CPU reduction.
There is only good news here:
► No change in I/O times for 4 KB pages.
► Significant sequential I/O time improvement for those table spaces with greater than 4 KB
page sizes, as soon as the larger CI sizes are utilized in new-function mode. See 4.10,
“New CI size” on page 199.
► DB2 V8 removes the limit of 180 CIs per I/O for list prefetch and castout I/O requests. See
8.4, “DB2 I/O CI limit removed” on page 333.
► Compression, with the dictionaries now above the bar, is even more widely applicable, and
can help in reducing I/O.
By far the biggest impact in DB2 V8 for performance is related to the introduction of the 64-bit
architecture. The reason for moving to 64-bit architecture is that leading edge customers were
running into virtual storage constraint problems. For more information on this problem, see
the article on DB2 UDB for z/OS Storage Management by John Campbell and Mary Petras at:
http://www.idug.org/idug/member/journal/mar00/storage.cfm
The DB2 V8 implementation of 64-bit virtual storage is good news for installations that had
virtual storage constraint problems in the past. Many of them had to rearrange and reduce the
main DB2 storage consumers to avoid running into out-of-storage conditions; this new
configuration may not have been as optimal from a performance point of view. However, you
had no choice but to reduce storage utilization to avoid these out-of-storage conditions.
DB2 has moved several critical pools above the 2 GB bar, and left some below. Now in DB2
V8, with many main storage areas moving above the 2 GB bar, a possibility exists to enlarge
these storage areas, which in turn, can result in much better performance. However, be
careful when looking at thread storage. Most of the thread storage still remains below the bar,
including the application’s local dynamic statement cache, so carefully monitor thread-related
storage.
One observation to note is that both the DBM1 and IRLM address spaces exploit 64-bit virtual
addressing. The other DB2 address spaces, DIST, MSTR and SPAS, do not yet exploit this
technology.
12 DB2 UDB for z/OS Version 8 Performance Topics