db_file_multiblock_read_count parameter helps us controlling the numbers of blocks being brought up to the buffer cache in one I/O action. In older oracle releases, this parameter was usually set between 4 and 16 on OLTP environments and up to 64 on DWH environment.

Starting 10gR2, db_file_multiblock_read_count  is being set automatically depends on your OS I/O size and buffer cache size.

What happens is that even when you tune your system by optimizing the multiblock parameter, when you then upgrade to 11g (Fresh installation) Oracle might set up the default to an irrelevant number.  So, for instance, if you work on RAC OLTP based system, and your multiblock is set on 8 you should expect a change of this parameter with major performance degradation.

I recently visited a customer who suffered from some nasty waits on “gc buffer busy acquire” as well as other GC related wait events right after upgrading to 11g. Further investigation and a stress test validated the assumption that this is due to the change of the multiblock parameter (from 16 to 128).

The reason for this behavior is clear- since one node keeps a large amount of blocks in the buffer cache, and the second node tries to acquire access to the same blocks (intense OLTP operations) it will wait on cache fusion events.

So be conscious about it!

Ido