Re: 10g RAC and db_multi_block_read_count

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Thu, 6 Aug 2009 09:45:07 -0500
Message-ID: <ad3aa4c90908060745j53f04db9w2a91b367a9d48e13_at_mail.gmail.com>

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:
> http://www-900.ibm.com/cn/support/viewdoc/detail?DocId=2411083L10001
> 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
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Aug 06 2009 - 09:45:07 CDT