Quick DB2 Performance Check-up

The following document aims to provide a quick way of checking whether a particular DB2
subsystem, on which your application or the product you are responsible for runs, is in fact in good
conditions. The information provided is therefore very partial, but it should be enough to detect
possible problems with the DBMS before delving into your application or your product’s own
performance tuning. The examples provided have been obtained with the Bool & Babbage DB2
monitor.

REORGANIZATION

Check when the database was reorganised for the last time and whether the statistics have been
since updated and rebind performed.

-- REORG DATE WITH TABLE NAME

SELECT A.DBNAME, A.TSNAME, B.NAME, ICTIME, ICDATE, ICTIME
FROM SYSIBM.SYSCOPY A,SYSIBM.SYSTABLES B
WHERE A.DBNAME='CSDSAM01'
AND ICTYPE IN ('W','X')
AND ICDATE < '990000'
AND A.TSNAME=B.TSNAME
ORDER BY ICDATE DESC,ICTIME DESC

-- RUNSTATS REORG'ED TSNAMES

SELECT NAME,STATSTIME
FROM SYSIBM.SYSTABLESPACE
WHERE DBNAME='CSDSAM01'
AND NAME IN(
SELECT TSNAME
FROM SYSIBM.SYSCOPY
WHERE DBNAME='CSDSAM01'
AND ICTYPE IN ('W','X')
AND ICDATE='??????')

-- REBIND REORG'ED OBJECTS

SELECT NAME,BINDTIME
FROM SYSIBM.SYSPACKAGE
WHERE COLLID='M24TSO'
AND NAME IN(
SELECT DNAME
FROM SYSIBM.SYSPACKDEP
WHERE BTYPE='R'
AND BNAME IN (SELECT TSNAME
FROM SYSIBM.SYSCOPY
WHERE DBNAME='CSDSAM01'
AND ICTYPE IN ('W','X')
AND ICDATE='??????'))

-- TSPACE TO REORGANISE
SELECT DBNAME, TSNAME, CARD, (NEARINDREF + FARINDREF) * 100 / CARD
FROM SYSIBM.SYSTABLEPART
WHERE ((CARD > 0 AND (NEARINDREF + FARINDREF) * 100 / CARD > 1)
OR PERCDROP > 0)
AND DBNAME='CSDSAM01'

-- INDEX TO REORGANISE
SELECT IXNAME, IXCREATOR, LEAFDIST
FROM SYSIBM.SYSINDEXPART
WHERE LEAFDIST > 200
AND IXCREATOR='YCSSAM'

Make sure, thorough a DB2 monitor or from the DBMS log, that the number of locks
due to multiple access attempts to the same database page is not too high.
<RESOURCE UNAVAILABLE
REASON 00C9008E
TYPE 00000302
NAME CSDSAM01.sam_table.page>

If there are too many locks, consider whether it is worth establishing Row Level
Locking on these table spaces. (ALTER TABLESPACE tablespacename LOCKSIZE ROW)

EDM SUBPOOL

You might want to check the percentage of free pages at peak time (around 10%
could be a reasonable value). A better indicator is though the percentage of
times that CT, DBD, PKG are found in the buffer EDM pool (at least 80% would be
acceptable). A high value here is a good indication of the correct (or
overestimated) size of the EDM pool. Any tuned production system should never
have a value other than 0 for the number of “FAILS DUE TO POOL FULL”. Any such
occurrence would cause threads to wait.

EDMPL(DBD)
% FOUND
£ PAGES % PAGES REQUESTS LOADS IN POOL
------- ------- -------- ------- -------
FREE PAGES 1,384 6.2
SKCT'S 2,553 11.3
SKPKG'S 11,159 49.6
CT'S 49 0.2 9,937K 4,900 100.0
DBD'S 7,078 31.5 7,345K 1,417 100.0
PKG'S 277 1.2 35,512K 13,768 100.0

TOTAL 22,500 52,795K 20,085 100.0

SQL CACHE 0 0 0 0.0

BUFFER POOL

Here you could check the ratio of number data pages updates to data pages
written to DASD (VP HIT RATIO RANDOM – random GETPAGE requests). The lower this
figure the more efficient is the use of the buffer pool, although this is not
always the case because this value is workload dependent. If a batch job is
designed to sequentially update a table, then many updates will take place
before the records are actually written. On the contrary, if the records are
being randomly updated, it is likely that they will be written back to disk
before they get a chance to be updated again 1 .
A more reliable indicator could be the number of GETPAGES satisfied with data
already in the pool (BUFFER UPDATES TO PAGES WRITTEN) whose percentage value
should be as high as possible. In addition, no Degradation Factors thresholds
should ever be reached (PREFETCH DISABLED – NOBUFFER and DM CRITICAL THRESHOLD
REACHED).

BFRPL(BP1,DELTA)
BUFFER UPDATES TO PAGES WRITTEN........40.8% INUSE(*)/THRESHOLDS
VP HIT RATIO RANDOM/ALL.......95.9%/...64.2% 0 ...25...50...75..100
HIPER POOL HIT RATIO..................100.0% VP ! D S C !
DM CRITICAL THRESHOLD REACHED..............0 HP ! !
IMMEDIATE WRITES (IGNORE IF DMC = 0)......79 -- LAST ALTERED --
BUFFER STATUS OK. UNKNOWN
DATA SHARING STATUS OK
NO THRESHOLDS HAVE BEEN EXCEEDED.

DEGRADATION FACTORS
THRESHOLDS REACHED PREFETCH DISABLED PARALLEL I/O
DWQT..................0 NO BUFFER.............0 GETPAGE FAILED........0
VDWQT.................0 NO READ ENGINE........0 PREFETCH AT 1/2.......0

1 By default, DB2 writes pages to disk when the number of modified pages exceeds 50% of the buffer pool or 2 checkpoints have been taken
without the data being written back to disk
 DM CRITICAL...........0 PREFETCH AT 1/4.......0
NO WRITE ENGINE.......0 STREAMS REDUCED.......0
EVENTS DEGRADED..............0
MIG DATASETS..........0
RECALL TIMEOUTS.......0

RID POOL

It is used for sorting row identifiers (RIDs) for multiple index access and list
prefetch functions. A RID pool failure is not necessarily a problem.

RIDPL
TOTAL BLOCKS: 187 BLOCKS AVAILABLE: 187

MAXIMUM USED: 212 BLOCKS IN USE: 0 (0.0%)

- - - - - - - - - - - - - - - - - FAILURES - - - - - - - - - - - - - - - - - -

EXCEEDED RDS LIMIT: 0 INSUFFICIENT POOL SIZE: 0

EXCEEDED DM LIMIT: 0 TOO MANY CONCURRENT: 0

LOG BUFFERS

Check that there are enough available output log buffers, in which case the
field for “Unavailable Output Log Buffers” should be quite small, hopefully
zero.

DLOGS
- - - - - - - - - - - - - - - - - BUFFERS - - - - - - - - - - - - - - - - - - -
BUFFER SIZE(K) 400 CI'S CREATED 111,817 WRITE REQ-FORCE 5,336
£ BUFFERS 100 WRITES 2,970K WRITE REQ-NOWAIT 2,965K
WRITE THRESHOLD 20 THRESHOLD %-BFRS 20 WRITE REQ-WAIT 0
INPUT BUFFER(K) 28 WAITS UNAVAIL.BFRS 0
% FORCE REQS 0%

TABLESPACE I/O

Check the average I/O wait for each table space and index access which should
generally be around 2 ms for asynchronous read (sequential pre-fetch 2) and 20
ms for synchronous read (specific page read). If the average overall I/O time is
greater than 20 ms investigate the reasons looking at the disk content, cache,
channels etc.

DBIOR(SO,DB,TOTAL)
DATA TABLE I/O I/O MAX AVG
BASE SPACE P COUNT % IOWAIT IOWAIT
-------- -------- - -------- ----- --ms-- --ms-- 0 ...20...40...60...80
CSDSAM01 SAM25400 81 0.0 1184 115 ! ********************
CSDSAM01 SAM25420 244 0.0 3679 151 ! ********************
CSDSAM01 SAM25450 338 0.0 212 11 ! **
CSDSAM01 SAM25460 6 0.0 20 9 ! **

THREAD ELAPSED TIME

After starting a sample batch or a sample command on-line, view the user details
to determine how much of the elapsed time is due to DB2 work and how much of it
is application time. The DB2 wait time plays also an important role in the total
elapsed time.

2 Sequential pre-fetch is a DBMS technique by which sequential activity is automatically detected and successive records to the one requested are
fetched in advance in the assumption that they might be shortly needed.
DUSER
PARM ==> ZAVSAMH1 ROW 1 OF 124 SCROLL=> CSR
EXPAND: MON(USER), UTRAC, ST(START TRACE), LOCKE, EXPLAIN, PT
ACCOUNTING: ENV, ELAPSED, SQLCOUNTS, BPOOL, LOCKS, PRLL, RTN, DDF
CURRENT........14:06:44.91 PLAN................M24TSO TYPE..............ALLIED
START..........14:06:29.41 AUTHID.............EE02591 CONNECT........BATCH/TSO
ELAPSED..............15 s ORIG PRIM AUTH.....EE02591 CORR ID.....ZAVSAMH1
STATUS.............IN-APPL COMMITS..................0 ROLLBACKS..............0
------------------------------------------------------------------------------
RUNTIME ANALYSIS IN DB2 IN APPL. TOTAL %IN DB2(=) TOTAL(*)
---------------- -------- -------- -------- 0 ...25...50...75..100%
ELAPSED TIME 1,940 ms 14 s 15 s ! ==****************** !
CPU TIME 102 ms n/a n/a ! !
DB2 WAIT TIME 1,777 ms ! == !
- - - - - - ACTIVITY - - - - - - - - - - - KEY INDICATORS - - - - - - -
TOTAL SQL.....................746 TIME SINCE LAST COMMIT - 13 s
GETPAGES....................1,040 SQL: SELECT= 163, FETCH= 214
SYNC READS (PRLL=00) .........218 SQL: INS= 0, UPD= 0, DEL= 94
PREFETCH PAGES READ............55 I/O RSP: SYNC= 8,012 us, ASYNC= 30 ms
UPDATES/COMMIT................0.0 RID LIST PROCESSING USED = 20
BFR HIT RATIOS:...VP= 74%,HP= 0%