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.

The possible increase in thread footprint in migrating to V8 is currently estimated to be<br />

between 30% and 70%. This is based on the laboratory measurements thus far.<br />

For more in<strong>for</strong>mation on the buffer pools in <strong>DB2</strong> V8 and related per<strong>for</strong>mance implications,<br />

refer to Chapter 4, “<strong>DB2</strong> subsystem per<strong>for</strong>mance” on page 127.<br />

2.5.3 Increased number of deferred write, castout and GBP write engines<br />

As the storage constraints are lifted, the workload may increase. As a result, <strong>DB2</strong> increases<br />

the maximum number of deferred write, castout and GBP write engines from 300 to 600. This<br />

increase should alleviate engine not available conditions.<br />

For more in<strong>for</strong>mation on these write engines and their per<strong>for</strong>mance implications, refer to<br />

Chapter 4, “<strong>DB2</strong> subsystem per<strong>for</strong>mance” on page 127.<br />

2.5.4 EDM pool changes<br />

One of the largest virtual storage consumers is usually the EDM pool. With <strong>DB2</strong> V7 some<br />

virtual storage relief was provided by the capability to move part of the EDM pool to a data<br />

space. Further enhancements are provided by <strong>DB2</strong> V8.<br />

In this section we discuss:<br />

► Dynamic statement cache<br />

► DBD cache<br />

► Plans, packages and DBDs<br />

For more in<strong>for</strong>mation on the EDM pool and its per<strong>for</strong>mance implications, refer to Chapter 4,<br />

“<strong>DB2</strong> subsystem per<strong>for</strong>mance” on page 127.<br />

Dynamic statement cache<br />

In <strong>DB2</strong> V7 dynamic statements are cached in the dynamic statement cache only if the<br />

DSNZPARM CACHEDYN is turned on. In <strong>DB2</strong> V8 caching is enabled by default (new install)<br />

and the dynamic statement cache is moved above the 2 GB bar. This can provide additional<br />

storage relief to the DBM1 address space in case a data space was not used.<br />

DBD cache<br />

In addition, a new DBD cache is created <strong>for</strong> the storage of DBDs and also allocated above the<br />

2 GB bar. Segregating the DBDs from the EDM pool relieves contention from other objects in<br />

the EDM pool. <strong>DB2</strong> V8 can support more and larger DBDs adding to <strong>DB2</strong> V8’s scalability.<br />

Plans, packages, and DBDs<br />

Plans, packages, and DBDs are all stored in the directory. There is minimal per<strong>for</strong>mance<br />

overhead running in CM because <strong>DB2</strong> plans, packages, and DBDs are different between V7<br />

and V8. This overhead can be alleviated <strong>for</strong> plans and packages by rebinding them. We<br />

recommend rebinding anyway to take advantage of V8 access path improvements, avoid<br />

conversions and enable faster processing.<br />

Important: Rebind plans and packages once you are com<strong>for</strong>table with CM.<br />

If you can live with the overhead during CM and cannot rebind twice, then rebind once you<br />

are in NFM.<br />

20 <strong>DB2</strong> <strong>UDB</strong> <strong>for</strong> z/<strong>OS</strong> <strong>Version</strong> 8 Per<strong>for</strong>mance <strong>Topics</strong>

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

Saved successfully!

Ooh no, something went wrong!