Re: 10g RAC and db_multi_block_read_count

From: Andrew Kerber <>
Date: Thu, 6 Aug 2009 09:45:07 -0500
Message-ID: <>

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 <> 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 []
> Sent: Thursday, August 06, 2009 10:29 AM
> To:; Crisler, Jon
> Cc:
> 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.'

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

Original text of this message