Re: 10g RAC and db_multi_block_read_count
Date: Thu, 6 Aug 2009 09:45:07 -0500
This is pure speculation, but perhaps when the particular table has a significant amount of data in the remote cache.
A local query is run requiring a full table scan (thus, dbfmbrc is an issue), a smaller block size will result in less data coming across the interconnect from the remote cache, thus reducing the waits.
On Thu, Aug 6, 2009 at 9:35 AM, Crisler, Jon <Jon.Crisler_at_usi.com> wrote:
> I saw a blog for a similar RAC GCR issue related to large
> multi-block-read-counts- it was long on the workaround but short on the
> symptoms so I did not use it as a definitive resource. I will try to
> find more info.
> -----Original Message-----
> From: Yong Huang [mailto:yong321_at_yahoo.com]
> Sent: Thursday, August 06, 2009 10:29 AM
> To: greg_at_structureddata.org; Crisler, Jon
> Cc: oracle-l_at_freelists.org
> Subject: Re: 10g RAC and db_multi_block_read_count
> > I am struggling to think of any significant difference
> > that RAC would introduce, so I would comment that it
> > makes no difference
> This question was recently raised in another forum. The poster
> had 9208 RAC FOR AIX and dfmbrc was 16, set by itself, and had
> lots of 'global cache cr request' waits (and UDP "socket buffer
> overflows" in `netstat -s'). He changed the parameter to 4 and
> solved the problem. He finally posted this reference:
> and quoted Note:228647.1. I couldn't read the Metalink note, but
> after lots of reading pretty much concluded it's a port-specific
> bug although I can't point out the exact bug number (most are
> marked duplicate or incomplete).
> Yong Huang
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-lReceived on Thu Aug 06 2009 - 09:45:07 CDT