Centinul and Mathew covered the other side of the problem – if the author wanted to save that section of the book from the trash bin, what would need to be added or changed to improve the clarity and accuracy.

Radoslav touched on some of the “touchy” points that affect the quality of the Oracle Database material found on the Internet through search engines. The points that he makes have been issues that I too have experienced. The OakTable website (http://www.oaktable.net/main) has a custom Google search engine, much like the one on Mr. “E”‘s site, that re-weights the search results so that less debatable material floats to the top of the search results.

If someone were to compare the the referenced book page and the articles listed directly below “A Google search found similar information here:” it seems that the contents of the articles are often direct copies of pages from the books, so it appears that you are correct. Take for example the information in the book that describes 10046 trace files which is located near page 430 in the book. If someone were to search the Internet for phrases from that section of the book, one of the pages that will be found is this one, dba-oracle.com/t_10046_tracing_events.htm, which is listed as being written by Robert Freeman. Another web page that will be found is this one, dba-oracle.com/t_grid_rac_events_in_Oracle.htm, which is listed as being written by Mike Ault.

I agree with your comment regarding problems with Internet searches. The author of this book addresses that problem on page 110. Fortunately, pages like this blog article are already indexed on Google. For example, if someone right now were to search Google for:
db_block_size db_file_multiblock_read_count

This blog article series, specifically part 3 which now has a comment by Jonathan Lewis, is listed as the second item in the search results. The people who leave comments on this blog are helping to improve the Google search results.

Why should the size of the tablespace have a direct impact on the size of the block ?

where the large object full scans will be occurring

Does this mean any large objects that I may scan should all be moved into a single tablespace ?

The db_file_multiblock_read_count parameter is only applicable for tables/indexes that are full scanned.

Not a lot of people know this (and I wouldn’t expect the author of the “definitive reference” to know it) – but the db_file_multiblock_read_count also has an impact on the costs derived for bitmap indexes.

the db_file_multiblock_read_count should always be set to a value that sums to …

A single value can’t sum to anything.

the largest supported blocksize of 32k

Is this also true on a platform that doesn’t support 32KB block sizes ?

I usually buy a book because I know it’s useful and almost everything is correct. Of course, everybody makes mistakes, even the best experts do (i.e. http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2680538100346782134 ). But they do it much less often..
The problem is that pages owned by Mr. “E” are usually on top in google search and junior members of Oracle community usually do not realize they should be especially aware whenever they visit them, because they can be easily adopt some myths, half-truths and “silver bullets” from an “expert”. It seems the Mr. “E” book has the same “quality” as the Mr. “E” sites.

Nice additional information. I think that with the introduction of system (CPU) statistics we need to be very careful when abbreviating the DB_FILE_MULTIBLOCK_READ_COUNT parameter. The system (CPU) statistics have a parameter that is named MBRC which is used for execution plan costing purposes (when workload system statistics are in place). Setting that system statistic to too high of a value can cause problems (reference: http://hoopercharles.wordpress.com/2009/12/27/high-value-for-mbrc-causes-high-bchr-high-cpu-usage-and-slow-performance/). I have seen a couple of people abbreviate the DB_FILE_MULTIBLOCK_READ_COUNT parameter as DFMBRC (or maybe DBFMBRC), or something similar just to avoid confusion.

Any other problems with the quote?

I believe in the book review I supplied a link to a test performed by Greg Rahn. Greg demonstrated how the value of the DB_FILE_MULTIBLOCK_READ_COUNT must be specified in terms of the database default block size. Oracle will automatically scale up or down for the tablespaces with non-default block sizes. Thus, if the DB_BLOCK_SIZE is set to a 8KB block size and DB_FILE_MULTIBLOCK_READ_COUNT is set to 32, Oracle will automatically scale the DB_FILE_MULTIBLOCK_READ_COUNT down to 16 blocks when it encounters a tablespace with a 16KB block size, and scale it up to 64 when it encounters a tablespace with a 4KB block size. Considering the quoted text, what would be the point of multi-block reads if the DB_BLOCK_SIZE is set to a 32KB block size. The clarity of your paragraph is much better than the original, but I think that more still needs to be added.

Does the DB_FILE_MULTIBLOCK_READ_COUNT apply during an index full scan (NO)? Does it apply during an index fast full scan? Does it apply to index prefetching? Does it apply to anything else?

I’d only do this with consideration to the rest of the system and how this might affect the costing of all query plans.

I don’t believe that this approach holds any more since 10.2 – I think the optimizer dynamically sets the MBRC value based on how many active sessions are connected. The advice I’ve heard is not to explicitly set MBRC at all (and I haven’t come across any situations yet where I have needed to explicitly set MBRC. I’m reasonably sure though that they may exist). I don’t change MBRC from default these days – working on 11GR1.

I’m interested to find out what you view is in terms of explicitly setting (or not) MBRC.

But to your quote:

I guess the quote is trying to say something similar to my first paragraph above.

M.

I don’t think this quote makes a lot of sense to begin with. the units of db_file_multiblock_read_count are blocks, not bytes. If a person read this and implemented this without thinking they could set it to a very unrealistic value. Imagine a db_multiblock_read_count of 32768! That implies a maximum I/O size of 256MB for a 8KB block size database.

Another interpretation, which agrees with the examples you stated are in the book, is that the db_file_multiblock_read_count should sum to a maximum I/O size of 32K. I think this would significantly short change an I/O subsystem in most cases. My guess is that what he should have said is:

“When using multiple block sizes the db_file_multiblock_read_count should be set such that the result of db_block_size*db_file_multibock_read_count is a multiple of the block size of your tablespace with the largest block size which does not exceed the maximum I/O size of your system.”

Additionally in NOWORKLOAD statistics are used setting an incorrect value of db_multiblock_read_count could make Oracle choose plans that are not best suited for the data set.

Hopefully this is what you are looking for

I will get you started. What is the difference between “sum” and “product”? Now, keeping in mind that the author of this book labeled me as a “spelling Nazi” (reference http://forums.oracle.com/forums/thread.jspa?threadID=976659 – yes, that comment was edited, the original version that hit my email box contained words that I suspect violated the OTN terms of service), I feel that I have made my contribution to what is wrong with this quote.