19.06.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 2. Per<strong>for</strong>mance overview<br />

2<br />

Scalability, availability, and per<strong>for</strong>mance are key reasons to choose <strong>DB2</strong> as your premier<br />

enterprise database server. These reasons are mandatory criteria <strong>for</strong> <strong>DB2</strong> in order to allow<br />

growth and be able to exploit (in a balanced manner) increasing processor speed, larger<br />

central storage and faster I/O devices. However, two major inhibitors slowed down growth <strong>for</strong><br />

some leading edge users. These inhibitors were the size of virtual storage available per<br />

address space and the persistent difference in speed between processors and disks’ service<br />

time.<br />

The 2 GB virtual memory size, dictated by the 31-bit MVS architecture, was an inhibitor to<br />

growth <strong>for</strong> the DBM1 address space where many <strong>DB2</strong> throughput-related pools were<br />

acquired. This limited addressing capability in turn reduced the size of the buffer pools that<br />

could be assigned <strong>for</strong> accessing data. The theoretical limit <strong>for</strong> the virtual buffer pools is 1.6<br />

GB, but realistically, <strong>for</strong> most high-end customers, it is less than 800 MB, regardless of the<br />

availability of real storage. <strong>DB2</strong> V7 customers, needing a larger buffer pool, likely use data<br />

space buffer pools, and are able to use 10 to 20 GB.<br />

The architectural solution <strong>DB2</strong> V8 provides is to adopt the 64-bit z/<strong>OS</strong> architecture and<br />

remove the major storage inhibitors. Both the DBM1 and IRLM address spaces now run in<br />

64-bit addressing and take advantage of new 64-bit instructions of the zSeries architecture.<br />

This allows <strong>DB2</strong> to move several storage pools above the 2 GB bar and provides customers<br />

virtual storage constraint relief. In turn, this allows exploitation of the processor speed and<br />

usage of the real storage size of the largest systems.<br />

Savvy users are cautious about changing long-established capacity rules and will ask you<br />

pertinent questions similar to the following ones:<br />

► What is the impact of the new architecture in terms of CPU and I/O utilization?<br />

► How is the virtual storage layout changing? What is still below the 2 GB bar, and what has<br />

moved above the bar?<br />

► How can I make sure I have enough real storage to support my workload today, and<br />

tomorrow?<br />

► What else needs to be done to take advantage of the architecture?<br />

► What new DSNZPARMs affect my real storage consumption?<br />

► What old DSNZPARM default settings may have changed to affect storage and CPU<br />

considerations?<br />

© Copyright <strong>IBM</strong> Corp. 2005. All rights reserved. 9

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!