Thanks for leaving the comment. Now that you mention MREADTIM, SREADTIM, and MBRC, I will mention Chris Antognini has a well timed blog article (http://antognini.ch/2010/11/workload-system-statistics-in-11g/) that shows an odd bug with MREADTIM and SREADTIM – yes, SREADTIM is greater in Chris’ blog article, but that is not the point of the blog article. You will see in the third article in this series that I had the following system (CPU) parameters set on my laptop:

-----------------------------
SYSTEM STATISTICS INFORMATION
-----------------------------
  Using WORKLOAD Stats
  CPUSPEED: 2714 millions instructions/sec
  SREADTIM: 0.100000 milliseconds
  MREADTIM: 0.200000 millisecons
  MBRC: 78 blocks
  MAXTHR: 302080 bytes/sec
  SLAVETHR: -1 bytes/sec

Back in September I had collected workload statistics on the 11.2.0.1 database on the laptop and came up with some odd values for SREADTIM and MREADTIM – extremely large numbers on a laptop with a RAID 0 array of 256GB SSD drives. At the time I thought that I had just done something wrong, or that the numbers were so low that Oracle Database simply panicked, or some sort of number overflow happened, thus causing the odd values. It is a bit reassuring to see that Chris was able to identify the problem. So, I manually set the values for SREADTIM and MREADTIM to what I believed to be realistic values for the configuration. I *think* that I also saw odd numbers on the Enterprise Edition 11.2.0.1 database that was used for this blog article, so I copied the statistics from the Enterprise Edition 10.2.0.5 database as the standard for all of the tests.

I am hoping to finish part 4 of this blog article series today. The data load portion (the reproducible data) of the test requires between 1 and 3 hours for each database, so I ran out of time to complete the tests. The next article should be quite long.

Regarding your comment about MBRC and 8, you are correct that the value was set to 16. However, that value should only be used during the cost calculation when the query is hard parsed. The actual physical read size should be limited to the size of the smallest of the DB_FILE_MULTIBLOCK_READ_COUNT (defaulted to 128), or the physical extent size (initially 8 blocks, but increased to to 128 blocks, and then increased again) or 1MB (on most operating system platforms). The odd part is that Standard Edition continued to read 8 table blocks at a time (64KB) rather than increasing to 128 blocks at a time (1MB) once the first 16 table extents were processed. I have not yet found the reason for the 8 block limit – there might be a hidden parameter that limits the read size to 8 blocks, but I have not found that parameter yet.

(I haven’t read your other posts on the subject yet)

Strange behaviour, indeed. How does one implement an index range scan using multi-block, scattered reads?! And table access by index ROWID? The only situation I can think of where this would make sense would be if your MREADTIM was smaller than your SREADTIM (which explicitly is NOT the case in your tests). Well, maybe also if – as in your test – the physical order of the index leaf blocks matched the logical order very closely. But that would be way too much intelligence to expect from the Standard Edition CBO, given that – AFAIK – there is no statistic about this.
Also, your MBRC is 16, not 8…

Off to the next post, then.

Cheers,
Flado