Re: gc buffer busy from the same instance??

From: <stevedhoward_at_gmail.com>
Date: Sat, 9 May 2009 04:45:54 -0700 (PDT)
Message-ID: <fe3978e2-5fde-4cbd-ba1f-7c48328b80c4_at_o14g2000vbo.googlegroups.com>

On May 8, 3:10 pm, Steve Howard <stevedhow..._at_gmail.com> wrote:
> Hi All,
>
> 10.2.0.4 EE on SLES 10
>
> We have seen fairly significant waits recently on this during a large
> load recently.  We know which query is causing it and are submitting a
> fix, but my question is the following:
>
> When I select from gv$session, I see session x on instance 2 waiting
> on "db file sequential read" for a given file and block number.  I see
> session y, also on instance 2, waiting on "gc buffer busy" for the
> same file and block.  These are the only two sessions going after this
> block.
>
> I can understand (and would expect) this if session y was on instance
> 3, or whatever.  However, since both sessions are on the same
> instance, why is this not either recorded as "read by other session"
> or "buffer busy waits" event?
>
> Thanks,
>
> Steve

I found this in the docs, which to me still doesn't explain it...

http://download.oracle.com/docs/cd/B19306_01/rac.102/b14197/monitor.htm#CFAGAAGD

/

---

High concurrency is instead evidenced by the existence of the gc buffer busy event. This event indicates that the block was pinned or held up by a session on a remote instance. It can also indicate that a session on the same instance has already requested the block, which in either case is in transition between instances and the current session needs to wait behind it.

*************************************************************************************************************************/

How is a session on the same instance requesting a block the same as a transition between instances??

I'm sure the diagnostics pack (at least ADDM) uses the wait classes for its recommendations. If it sees this as a cluster class event, vs I/O, it may recommend different things (sometimes incorrectly)

I will open an SR for clarification and report back. Received on Sat May 09 2009 - 06:45:54 CDT