DB_BLOCK_SIZE and DB_FILE_MULTIBLOCK_READ_COUNT 4 – What is Wrong with this Quote?

5 12 2010

Decmber 5, 2010

(Back to the Previous Post in the Series)

I recently reviewed the book “Oracle Tuning the Definitive Reference Second Edition”, and did not provide an in-depth technical review of the entire book.  As I stated in a comment in the earlier blog article, I would like to clarify that my review on the Amazon site is not intended to suggest that people should not buy the book. As the publisher’s website states that the book is written for senior Oracle DBAs, I suggest that senior DBAs, Oracle Certified Masters, and other people who are able to research the book’s contents *should* buy the book and post reviews of the book that highlight specific content of the book indicating whether or not that content is correctly stated. Such feedback will be a benefit to the Oracle community, and could help to improve Oracle Database books that are published in the future. I think that we need to keep a positive outlook in order to see things improve

With that said, what is wrong with the following quote from page 530 of the book (please excuse the length of this quote, I tried to make it as short as possible without losing the context of the material, and without destroying the sentence structure)?

“Remember, the db_file_multiblock_read_count parameter is used to tell Oracle how many blocks to retrieve in the single I/O operation and the setting is platform-dependent. The most common settings ranged from 4 to 64 blocks per single multi-block I/O execution.

The ‘automatically tuned’ db_file_multiblock_read_count in 10gr2 and beyond uses external disk workload statistics that are gathered via the dbms_stats.gather_system_stats package to determine the optimal setting.

A sub-optimal setting for db_file_multiblock_read_count can running SQL performance because it can cause the optimizer to favor full-scan access. This would cause some beginners to adjust for this by turning the wrong knob, lowering the setting for optimizer_index_cost_adj instead of using dbms_stats.gather_system_stats.

10gr2 and beyond, the db_file_multiblock_read_count is not used to estimate the average number of blocks read and a separate metric for the estimated number of actual block reads. Instead, the optimizer computes two new values, one for optimizer costing and another for the number of I/O requests.”

What, if anything, is wrong with the above quote from the book?

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: