11 Replies Latest reply: Apr 23, 2010 3:06 PM by 692600 RSS

    gc cr block busy

      I encountered gc cr block busy event in an RAC env. Did a little bit research, and it is saying that even a select statement will suffer from Lgwr performance and has to wait the log flush to complete.

      Why it needs to wait for log flush to complete even a CR block is being selected?
        • 1. Re: gc cr block busy
          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.
          • 2. Re: gc cr block busy
            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.
            • 3. Re: gc cr block busy
              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.
              • 4. Re: gc cr block busy
                But why it needs to wait for log flush? It is just a CR.
                • 5. Re: gc cr block busy
                  Hi buddy
                  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?

                  • 6. Re: gc cr block busy
                    • 7. Re: gc cr block busy

                      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?

                      • 8. Re: gc cr block busy
                        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.
                        • 9. Re: gc cr block busy
                          How about the case in non-RAC?
                          • 10. Re: gc cr block busy
                            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.

                            • 11. Re: gc cr block busy
                              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