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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Thread-related storage is much larger in V8 to support all the new function consumed by<br />

threads. The main driver is support <strong>for</strong> much larger identifiers within <strong>DB2</strong>.<br />

IRLM address space<br />

IRLM V2.2 which is shipped with <strong>DB2</strong> V8, is now a 64-bit application in which the locks now<br />

always reside above the 2 GB bar. These changes also have a significant impact on virtual<br />

storage used by <strong>DB2</strong>, if you currently specify PC=NO.<br />

Refer to 4.6, “IRLM V2.2” on page 171, <strong>for</strong> a more detailed discussion of IRLM and virtual<br />

storage.<br />

MSTR address space<br />

The MSTR address space has not caused any problems related to being virtual<br />

storage-constrained. In addition, the MSTR address space is still all coded as 31-bit. We<br />

there<strong>for</strong>e have not done any specific studies on virtual storage usage of the MSTR address<br />

space in V8 compared with V7.<br />

Real storage<br />

An implication of the z/<strong>OS</strong> implementation of the z/Architecture in 64-bit mode is there is no<br />

more Expanded Storage. If a page or ‘frame’ needs to be paged out of real memory by the<br />

system, it is paged out directly to disk. This can have an extraordinary impact on <strong>DB2</strong><br />

per<strong>for</strong>mance, especially if the buffer pools, or part of the buffer pools, are paged out to<br />

auxiliary storage.<br />

<strong>DB2</strong> V8 requires more virtual storage to accommodate:<br />

► Bigger modules, control blocks, and working storage<br />

► Higher default and maximum buffer pool size, RID pool size, sort pool size, EDM pool size<br />

and authorization cache<br />

► More and larger user threads<br />

► More deferred write engines and castout engines (300 -> 600 maximum)<br />

► More parallelism enabled<br />

► Locks moved above the 2 GB bar<br />

This increased demand <strong>for</strong> virtual storage there<strong>for</strong>e increases the demand on the amount of<br />

real (or main) storage that is available on the system (maximum 512 GB on a z9 EC model<br />

S38 or S54) or LPAR (maximum 128 GB).<br />

There are messages regarding what storage is currently available but the storage in<strong>for</strong>mation<br />

contained in these messages can be overly optimistic. The real storage is by z/<strong>OS</strong> image or<br />

LPAR, and you could have several other <strong>DB2</strong> subsystems, each contending <strong>for</strong> the same real<br />

storage. The messages are documented in Table 4-7.<br />

Table 4-7 <strong>DB2</strong> storage messages<br />

Message Message in<strong>for</strong>mation<br />

DSNB536I Indicates that the total buffer pool virtual storage requirement exceeds the size<br />

of real storage capacity of the z/<strong>OS</strong> image.<br />

DSNB610I Indicates that a request to define or increase the size of the buffer pool exceeds<br />

the smaller of twice the amount of real storage of the z/<strong>OS</strong> image or 1 TB.<br />

DSNB508I Issued when the total size used by all buffer pools exceeds 1 TB.<br />

Chapter 4. <strong>DB2</strong> subsystem per<strong>for</strong>mance 153

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

Saved successfully!

Ooh no, something went wrong!