This content has been marked as final. Show 11 replies
It is Global Cache Current Block Busy event, it is very similar to the buffer busy event in the single instance, it means big contention on this blocks, or may be someone doesn't makes commits fast enough:)
Check the hot object using block#, determine sessions using this object analyze them.
Thanks for your reply.
I can see some reference mentions that this event can be a result of slow log flush. I am wondering why reading a cr block needs to wait for a log flush to complete.
The Slow log flush prevent sessions to commit fust enough and as result the buffers used by this sessions is not released fust enough resulting in buffer busy waits.
But why it needs to wait for log flush? It is just a CR.
But why it needs to wait for log flush? It is just a CR.+"The gc current block busy and gc cr block busy wait events indicate that the local instance that is making the request did not immediately receive a current or consistent read block. The term busy in these events' names indicates that the sending of the block was delayed on a remote instance. *For example, a block cannot be shipped immediately if Oracle Database has not yet written the redo for the block's changes to a log file.*"+
Is it satisfies You?
But in my case, the SQL is just a select statement to get a CR block from the remote instance. Why it still need to wait for the redo log write to complete?
In a non-RAC database, I think it doesn't wait for redo log write to complete before it reads a CR block. Right?
the reader instance needs CR block, the remote instance may have updated any row in block (not committed yet) and needs to create a CR block (PI) from redo to send to the requester, this preparation step will also cause the delay.
How about the case in non-RAC?
In the case of Non-RAC, there is only one modified copy that's there in the instance so there is no need to flush it before its CR copy can be sent to the requester. In the case of the RAC, many instances can be having the PI image and one would be having the most current( modified ) version of it. Before sending the CR copy to the requestor, either for write-read or for write-write, there would be a requirement to maintain that copy in the redo log file by LGWR. That's why the flush would happen even for select command.
The way that it can happen as I see it is, the moment that the remote instance request the block happens to be very close to the moment that a commit happens for that particular block in the owning instance. So in that case, a CR will not suffice and the buffer will be locked till the time it's flushed to redo; which means a wait for the block in the remote instance.
and indeed then the select statement may suffer (not always) from lgwr performance.
Edited by: Oldbarrel on Apr 23, 2010 1:06 PM