Cheers

Dejan

Paul illustrates the use of query perfectly. It’s important to get frequent observations, and querying v$session_wait manually a few times in a row really leaves a lot of room to miss quick transient events. An alternative could be to look at v$latch_misses (for example) to see an overall picture, but it’s not really granular in that you see cumulative stats and not a picture of what’s happening “now”. The other obvious limitation is that it’s looking at just the latches and nothing else. Likewise, you could query all the other dictionary tables individually to look for other waits. Steve’s query nicely points you in the right direction from the get-go.

Cheers,
Shakir

EVENT T0 T1 T2 T3 T4 T5 T6 T7 T8 T9
row cache lock 1
enqueue 1 1
SQL*Net more data from client 3 2 1 1 1
db file scattered read 1 1 1 1 1 1 1 2
SQL*Net more data to client 1 1 5 2 2 1 1
io done 2 1 1 2 1 2 2 2 2
file open 8 4 1 6 6 1 10 3 3
slave wait 5 5 5 5 5 5 5 5 5 5
buffer busy waits 19 4 5 12 6 10 14 5 4
SQL*Net message to client 38 13 29 37 39 24 36 32 11 10
log file sync 27 7 84 5 11 36 71 35 14 4
db file sequential read 59 37 31 44 46 29 51 37 25 30
latch free 249 250 355 340 178 284 126 220 13 17

See how, seen as together, the latch free stnads out as being clearly the problem here. In this case, I believe we were living with the old library cache hashing approach and we had a versioning problem. In any event, imagine if you only ran one observation and ended up with the one with 13… you might easily conclude this is a disk IO issue, what with the log file sync and db file seq read trumping your latch free.

Cheers
Paul

I dug up an old observation where the underlying problem is not latch free, however the latch free events exhibits the behaviour I’m talking about:

EVENT T0 T1 T2 T3 T4 T5 T6 T7 T8 T9
log file sync 1
SQL*Net more data from client 1
SQL*Net break/reset to client 1
db file parallel write 1 1 1 1 1 1 1 1 1 1
enqueue 1 1 1 1 1 1 2 2 3 1
SQL*Net message to client 1 2 2 1 2 1 1 1 4
db file scattered read 4 4 3 3 3 4 4 4 4 3
db file sequential read 21 21 24 23 23 23 22 19 17 21
latch free 1 5 23 41 46 57 66 6
buffer busy waits 180 180 181 181 181 181 181 181 181 181
file open 196 200 199 199 194 193 192 191 190 194

See how for some observations, it doesn’t appear at all? Meanwhile, for another observation only microseconds later, a full 66 sessions are simultaneously waiting on a latch? That’s what doing 10 observations allows you to catch when doing only one you might miss it and come to the wrong conclusion.

Cheers

Paul