Joined: 21 Feb 2009 Posts: 36 Location: South Portland, Maine
What could be the possible factors for a high wait time on DB2 access ?
Currently the program takes 5 CPU mins and around 1 hour of elapsed time.
Using Macro 4 Freezeframe -There is 62% wait time which mainly contributes to this elapsed time. 32% of this wait time is due to a single query straight forward query which uses all the primary keys to fetch columns of the table(huge table with 52 million records).
WHERE A = :A
AND B = :B
AND C = :C
AND D = :D
AND E = :E
Here A,B,C,D,E are the primary keys.
What could be the possible reason for such a high wait time for DB2 and how do i narrow down to the cause of it ?
Please let me know if any more information is required.
Your help on this would be appreciated.
- 1st thing is an explain so you sure it uses the Primary index.
- Is the wait time I/O wait time, Lock wait time, or CPU Wait time ?
- how many times is that statement executed ?
for IO wait :
- synchronous or asynschronous reads ?
- if stmt is executed a lot. does the input comes in order of the index or random?
- Clusterratio of the used index ? Is it clustering ?
- How long ago was the tablespace reorged ?
for Lock wait or CPU wait:
- check concurrent jobs.
synchronous reads take very long.
the reason for synchronous in stead of the much faster asynchronous :
if input is in order of PK : clusterratio = 66% for a clustering index this should be 100% and once it drops under 95% (90%) the table should get reorged.
or your input is in another order. If you sort your input (file or other cursor) in the order of the index you should start getting a lot more asynchronous reads.
if your index is huge = nlevels is high , suppose 6, then each select will need 7 getpages (6 for index and 1 for data):
when random access then it's every time 7-5 different pages (which are possible not in the bufferpool = 7-5 Synchronous IO)
when sequential almost all pages will be in the buffer, and occasionally the next block of 32 pages will be read while you are processing the previous block of 32 pages (= 1 asynchronous read after each 100 selects)