GC current block busy

Question

Hi ,
I have two node Oracle RAC.Version is 11.2.0.2
When i do an online inquire transaction for higher load, I am observing 'gc current block busy' in AWR as one of the top events.GV$SESSION_WAIT
doesnt show anything as below.
Kindly let me know how to tune it.
AWR top events.
DB CPU   32   64.34  
log file sync 5,972 9 2 18.36 Commit
gc current block busy 2,448 7 23 13.32 Cluster
gc current block 2-way 4,665 3 1 5.41 Cluster
gc current grant busy 2,446 1 0 2.20 Cluster
SQL> SELECT
  INST_ID,
  EVENT,
  P1 FILE_NUMBER,
  P2 BLOCK_NUMBER,
  WAIT_TIME
FROM
  GV$SESSION_WAIT
WHERE
  EVENT IN ('buffer busy global cr', 'global cache busy',
            'buffer busy global cache');
  2    3    4    5    6    7    8    9   10   11
no rows selectedThanks

Answer 1

user10698496 wrote:
I have two node Oracle RAC.Version is 11.2.0.2
When i do an online inquire transaction for higher lRoad, I am observing 'gc current block busy' in AWR as one of the top events.GV$SESSION_WAIT
doesnt show anything as below.
Kindly let me know how to tune it.(Note: Your query against v$session_Wait doesn't seem to match the events listed in the AWR.)
(Note 2: Your snapshot seems to be for a very short time - which doesn't really give an idea of how serious the problem may be in the bigger picture.)
There are many GC events that you won't see in v$session_wait because the session doesn't know the event consuming the time until after the wait has completed - so when you check v$session_wait you will often see "gc cr request", or "gc current request" (I think I may have the names wrong, but I don't have an instance in front of me right now) - these are known as "placeholders" to Oracle and may change to things like "gc current block 2-way" or "gc current block 3-way".
You've looked at the ADDM (so you're licensed for the diagnostic), and seen the top object. Had you not done so I would have suggested looking at the "Segments by .." sections of the AWR report, checking the two sections on CR and CUR traffic; then check the "SQL ordered by ...." sections for the sections on global cache time. If your offenders are insert statements that match primary key indexes then you probably need to stop the instances from inserting into the same index leaf block at the same time.
A key question to ask is whether the primary key is a meaningless value generated by an Oracle sequence; if so have you set the sequence cache size to a large enough value (in the order of thousands or tens of thousands). This is the first step in resolving sequence-based RAC issues. (There are other strategies - but we need more information to determine best action.)
Regards
Jonathan Lewis
P.S. The best place on the Internet for information about details of how RAC works and the interpretation of RAC events is probably Riyaj Shamsudeen's blog at: http://orainternals.wordpress.com/
Edited by: Jonathan Lewis on May 14, 2012 8:24 AM