I'm afraid I don't really understand this? If the problem is that the block size is too small and so excessive chaining is happening, then pretty much the only thing one can do is to recreate the db. For disk reads surely what you do is set db_file_multi_block_read_count such that db_file_multi_block_read_count*db_block_size to the amount that your system can read from disk at any one time (at least in 8i - I'd use system stats probably in later versions). In such a case then changing db_file_multi_block_read_count would be a waste of time no? On Thu, Dec 4, 2008 at 3:49 PM, Stephens, Chris <chris_stephens@xxxxxxxxxxxx > wrote: > Alternatively, I think db file multi block read count may simulate a > larger block size. > > > > *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Dennis Williams > *Sent:* Thursday, December 04, 2008 9:06 AM > *To:* eugene.pipko@xxxxxxxxxxxx > *Cc:* oracle-l@xxxxxxxxxxxxx > *Subject:* Re: Changing block size > > > > Eugene, > > > > As you've probably understood from your replies, DB_BLOCK_SIZE is the one > parameter that can't be changed after the database is created (there are > more options with 10g). Perhaps if you stated why you want to change this, > we can provide you more useful suggestions. Often people assume stuff > like by doubling the block size their performance will double. Also, this is > a pretty old database version, and not the latest Windows server version. > I'm always reluctant to make substantial changes on something that > old. Might be a better idea to migrate the database to recent versions. > > > > Dennis Williams > > > CONFIDENTIALITY NOTICE: > This message is intended for the use of the individual or entity to which > it is addressed and may contain information that is privileged, > confidential and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient or the employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email reply. > > > -- Niall Litchfield Oracle DBA http://www.orawin.info