Re: Seeking understanding of my "gc cr multi block request" waits

Rich,

The problem with 'gc cr multiblock request' wait is, the wait is not complete till all the required blocks are read in to waiter's cache. This may take little longer time depending on the out come of the request (lock grant vs block tranfer).
If you get the grant you can go ahead and read the blocks from the disk or you may get the blocks via wire if the blocks are cached somewhere in the global cache.

If there is a buffer overflow (or some sort of werid issues like the bug you mentioned) you may see some blocks lost in transfer and that may take little longer than expected. BTW do you see any statistics mentioning blocks lost?
You may want to check your UDP buffer settings..Also you may need to do a KCL tracing (or event 10708) to figure out what is happening undercovers. Another simple option is to check whether you have any 'cr request retry' or 'cr request failure' events followed by the gc request.

Coming back to your questions, your understanding about 'place holder' wait is correct. Also your expectation of the fixup waits (2way/3way) also correct. But due to bug 3423615, the fixup waits are not shown in the V$views.In short your assumptions 1 and 3 are correct. The above mentioned bug prevents showing the fixup waits in the views.

BTW Do you care to send your raw trace file?

-Gopal Received on Thu Jul 19 2007 - 11:23:03 CDT