|
View previous topic :: View next topic
|
| Author |
Message |
ganeshprasanna
New User
Joined: 21 Feb 2009
Posts: 36
Location: South Portland, Maine
|
|
|
|
Hello,
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).
Query details:
| Code: |
SELECT COL1,
COL2,
.
.
.
COL260
FROM TABLE
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.
Thanks,
Ganeshprasanna |
|
| Back to top |
|
 |
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
- 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. |
|
| Back to top |
|
|
ganeshprasanna
New User
Joined: 21 Feb 2009
Posts: 36
Location: South Portland, Maine
|
|
|
|
I can answer some of them right now..
| Quote: |
| 1st thing is an explain so you sure it uses the Primary index. |
Yes. It uses the primary index.
| Quote: |
| - Is the wait time I/O wait time, Lock wait time, or CPU Wait time ? |
I got some details from BMS apptune. Which says lock time - 0.
I assume is I/O wait time.
| Quote: |
| synchronous or asynschronous reads ? |
All are synchronous reads
| Quote: |
- Clusterratio of the used index ? Is it clustering ? |
Clusterratio - 0.66000
CLUSTERING - Y |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
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) |
|
| Back to top |
|
|
|
|
