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

4.1 DB2 CPU considerations
With every new release of DB2, performance is always a challenge. DB2 V8 is no different.
For those applications not taking advantage of any V8 performance enhancements, some
CPU time increase is unavoidable to support a dramatic improvement in user productivity,
availability, scalability, portability and family consistency of DB2. In particular, enhancements
in:
► DBM1 virtual storage constraint relief with 64-bit addressing. A number of DB2 structures,
for example, buffer pools, have moved above the 2 GB bar.
► Long names and long index keys. Many DB2 names change from CHAR(8) or
VARCHAR(18) to VARCHAR(128). Maximum index key size also moves from 255 to 2000
bytes.
► Longer and more complex SQL statements. The maximum SQL statement size moves
from 32 KB to 2 GB.
► Extended support for Unicode. The DB2 catalog is now Unicode and you can combine
multiple CCSIDs in the same SQL statement.
In this section we discuss general subsystem performance considerations and what you may
see in V8 in terms of CPU utilization.
As processor power continues to improve, linear scalability, or the ability to exploit increasing
processor power without encountering a bottleneck that prevents the full CPU usage,
becomes more important. Bigger buffer pools and cache reduce the I/O bottleneck and CPU
overhead. Although most of the thread-related storage is still below the 2 GB bar, more
concurrent active threads could be supported in V8 as other storage areas are moved above
the 2 GB bar. However, whether more threads can be supported in V8 critically really
depends on how much thread storage is being used in V7. If the thread storage takes up the
majority of virtual storage in V7, there is no relief in V8.
Exploiting bigger and faster hardware without premature constraint is a major driver to the
virtual storage constraint relief enhancements in DB2 V8. For example, the z990 (GA in
05/03) is:
► 1.3 to 1.6 times higher MIPS compared to z900 turbo
► 1.8 to 2 times higher MIPS compared to z900
► 256 GB real storage up from 64 GB for z900
From V1R1 1984 to the present, real storage usage has grown in DB2 at about 20 to 30% per
release to support enhancements in performance and scalability, more and bigger buffer
pools, larger sort pools, and more concurrent threads. DB2 V8 continues this trend, by
removing bottlenecks which would have prevented the exploitation of bigger real storage.
64-bit addressing has brought its own performance challenges to DB2. For example, 64-bit
instructions are typically 50% bigger than 31-bit instructions. 64-bit addresses are twice as
big as 31-bit addresses. So, hardware registers and software control blocks which contain
virtual addresses all need to be bigger. All these bigger instructions and bigger registers take
longer to load and execute, (more bits and bytes must be staged into registers, destaged and
moved around the hardware). Studies have shown some 64-bit instructions can take as much
as 15% more CPU to execute. Other studies have shown that the same path length coded in
64-bit mode can take as much as 10% more CPU than coded in 31-bit mode.
The biggest difference is when 31-bit pointers have to be converted to 64-bit before being
used in AMODE(64). That overhead does not exist in V7, but is unavoidable since not all
components have been converted to 64-bit. Finally, it should be pointed out that the Unicode
Chapter 4. DB2 subsystem performance 129