>> It might, however, make a difference if the blocks belonging to the table are read by direct path read (commonly
>> used in Oracle Database 11.1 and above) or are read into the buffer cache by a db file scattered read – it also
>> makes a difference if the table’s blocks are already in the buffer cache.

which is what I meant when I wrote …

>> … a “change in timing” of Engine when it is called to recall the blocks …

Regards,
Donatello

It is interesting to see the application of logic to determine what did or did not happen – listing the clues that lead someone to believe that something happened, and then counter-clues that indicate that something else likely happened.

Good point about not seeing a “ALTER SESSION SET result_cache_mode = FORCE;” in the test case – I try to make certain that my test cases are reproducible, but there is always a small chance that a modified setting will be left over from a previous test case. As mentioned in the additional information that I added to the blog post, the total execution time required ranged between 00:00:37.05 and 00:00:39.37 for testing 128 values of the DB_FILE_MULTIBLOCK_READ_COUNT parameter. I was careful to hide that timing information when the blog post was originally created, in part so that I could see the rules of logic that people would use to determine what happened.

You are correct that in my test case it does not matter whether or not workload statistics or noworkload statistics used – in the test case it really does not matter what the calculated cost is based on the change to the workload statistics. It might, however, make a difference if the blocks belonging to the table are read by direct path read (commonly used in Oracle Database 11.1 and above) or are read into the buffer cache by a db file scattered read – it also makes a difference if the table’s blocks are already in the buffer cache.

The idea of the test, as mentioned by Chris, is to consider the real performance impact caused by articifically limiting the size of a multi-block read request below the typical 1MB limit. Consider if the database block size is 8KB, and collecting workload statistics results in a MBRC value (the average multi-block read size) of 64. The system can only obtain a MBRC value of 64 if the DB_FILE_MULTIBLOCK_READ_COUNT parameter is at least 64. Now, assume that testing shows that the system performance improves when the DB_FILE_MULTIBLOCK_READ_COUNT parameter is adjusted from the default (unset) value of 128 to a value of 32. If you change that parameter value to 32, you need to make certain that you either collect updated system statistics, or manually set the MBRC value to a lower value. So, one thing that could go wrong is that you set the DB_FILE_MULTIBLOCK_READ_COUNT parameter to a value smaller than the MBRC system statistic, which means that the MBRC statistic is then unrealistic. But, if you change the MBRC statistic, you risk changing the execution plans of most of the SQL statements that are executed in the database. If you are not using workload statistics, changing the value of the DB_FILE_MULTIBLOCK_READ_COUNT parameter could also change the execution plans.

1) did not specify
ALTER SESSION SET result_cache_mode = FORCE;
Or, you do not use the hint / *+ RESULT_CACHE */

the default for this parameter is ‘MANUAL’

2) the first run lasted 0 seconds, using the result cache
takes 0 seconds, at least from the second run onwards ….

Another thing caught my attention reading the comments ….
did not specify if your test is done with system workload statistics
noworkload or system statistics, because I think it does not matter in your tests.
In fact we are not comparing the cost of two queries, we’re just trying
to compare the execution times to vary db_file_multiblock_read_count, right?

but then, because it comes to recalculate the statistics system?
we are not discussing a change in cost, then the CBO, but
we’re talking about a change in timing of Engine when it is called
to recall the blocks …

I probably should have written that paragraph a little differently. The comment was definitely not intended to be critical of what you wrote in this section of the book. In the paragraph I attempted to describe how, when I was reading the test case, I should have glanced further down the page of the book to notice that you also described the possibility of leaving the DB_FILE_MULTIBLOCK_READ_COUNT parameter unset. I also should have remembered that the book, while targeting Oracle Database 11.1, also provides very detailed information about how the behavior of the earlier Oracle Database versions differed (other books fail to do this).

> While reading the test case, another thought raced through my mind: why is the author
> experimenting with the DB_FILE_MULTIBLOCK_READ_COUNT parameter – just leave
> it unset and make certain that system statistics are collected so that the MBRC system
> statistic is used

Because the engine determines the value without considering the real performance!
Hence my advice is to perform some tests and find out what the optimal value is.

Cheers,
Chris

Timur, at first I thought that the DBMS_UTILITY.GET_TIME function was not functioning correctly on my operating system platform. So, I enabled a 10046 trace and was surprised that buffered access (as you mentioned) was the cause of the unexpected test script output.

Steve – good point, automatic result caching might have been enabled – something that I had not considered.

Mohamed, good points, thanks for providing the link. Technically, because we are forcing a full table scan through a hint, we would not need to re-collect system statistics after each change of the DB_FILE_MULTIBLOCK_READ_COUNT parameter. I see your point about the DB_FILE_MULTIBLOCK_READ_COUNT parameter’s effect on the possible maximum value for the MBRC system statistic, so there is a potential need to re-collect system statistics after changing the DB_FILE_MULTIBLOCK_READ_COUNT parameter.

ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;

What I found in the trace file after making the above change is what I was expecting to find, and what caused me to pause when reading this test case. It is a good test case.

So far, the re-read of the book has not changed my original opinion of the book, as expressed in my original review. The updated review is currently 5 typewritten pages long through page 178 of the book, which is about on par with my review of the “Pro Oracle SQL” book. It appears that the errata for all books on the Apress site has disappeared, including the errata for your book. If I recall correctly, you have a page on your website that is dedicated to book errata. So that I am consistent with the practice used when reviewing other books, I will not look at that errata until my review is nearly finalized (and then likely will only mention where to find the errata). Such an approach will hopefully provide insight into what types of problems I might have overlooked in the other book reviews, and allow the book review for the “Troubleshooting Oracle Performance” book to be fairly compared with my other book reviews.

–

The test case is interesting, as others have mentioned in the comments below. I will try to not comment further in this article for at least 24 hours.

Best regards