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@xxxxxxx> 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@xxxxxxxxx] > Sent: Thursday, August 06, 2009 10:29 AM > To: greg@xxxxxxxxxxxxxxxxxx; Crisler, Jon > Cc: oracle-l@xxxxxxxxxxxxx > 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 > > > > -- > //www.freelists.org/webpage/oracle-l > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'