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.

In addition, <strong>DB2</strong> shows a high water mark <strong>for</strong> storage consumed by locally cached dynamic<br />

SQL statements. The high water marks are measured since the last time the IFCID 225<br />

record was externalized.<br />

Now, with <strong>DB2</strong> V8, if you look only at virtual storage, you get a partial view. <strong>DB2</strong> V8 now can<br />

allocate very large amounts of virtual storage above the bar which may not be backed by real<br />

memory. This can be very bad <strong>for</strong> per<strong>for</strong>mance. The DBM1 STORAGE ABOVE 2 GB counters<br />

do not provide the whole picture.<br />

So the IFCID 225 record and DBM1 Storage Statistics section of the <strong>DB2</strong> PE Statistics<br />

reports also report on DBM1 Storage usage above the 2 GB bar, as well as provide an<br />

indication of real storage frames used by the DBM1 address space. These statistics are<br />

displayed <strong>for</strong> both <strong>DB2</strong> V7 and <strong>DB2</strong> V8.<br />

REAL STORAGE IN USE reports on the amount of real storage in megabytes, used by the<br />

DBM1 address space. Ideally, this should be significantly less than the amount of virtual<br />

storage consumed. (TOTAL DBM1 STORAGE BELOW 2 GB + all the counters in TOTAL<br />

DBM1 STORAGE ABOVE 2 GB.)<br />

AUXILIARY STORAGE IN USE is the amount of storage in megabytes the DBM1 address<br />

space has allocated in auxiliary storage (disks). This should be zero or very close to it.<br />

The following points are indicators <strong>DB2</strong> may be suffering from storage-related problems, such<br />

as a <strong>DB2</strong> code error (storage leak) or a really stressed system due to a lack of real storage:<br />

► 100% real frames consumed. Note that although a physical machine may have 30 GB of<br />

real storage, a given LPAR may only have a fraction of this real storage dedicated.<br />

► An excessive number of auxiliary paging slots in use.<br />

► A general per<strong>for</strong>mance degradation.<br />

Dumps are also another useful tool to monitor storage usage within the DBM1 address space.<br />

However, they only capture a point-in-time picture of storage usage and do not capture peaks.<br />

An IPCS <strong>for</strong>matted dump using the parameter<br />

VERBEXIT DSNWDMP ‘ALL SM=3’<br />

produces the useful summary of DBM1 storage usage shown in Example 4-3.<br />

Example 4-3 DBM1 storage usage summary<br />

===Stack(SKB) total: 55196K 53M<br />

===Fixed subpool total: 384K 0M<br />

GMB total: 151755K 148M<br />

ADMF AGL system total: 3076K 3M<br />

ADMF AGL non system total: 93360K 91M<br />

ADMF AGL 31 total: 72064K 70M<br />

ADMF AGL VL total: 24372K 23M<br />

ADMF local total: 96436K 94M<br />

SQL cache total: 16080K 15M<br />

Variable subpool total: 119736K 116M<br />

Var+Fix+GMB+Stack total: 327071K 319M<br />

===Above the bar<br />

Fixed subpool total: 2604K 2M<br />

ADMF AGL 64 total: 76072K 74M<br />

ADMF AGL 64 system total: 0K 0M<br />

Variable subpool total: 154616K 150M<br />

VSAS blocks: 2201M<br />

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

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

Saved successfully!

Ooh no, something went wrong!