Ido

I am not sure if there has been. I agree that there have been some advances in hardware over the years and it may be of value to revisit it. If I find anything out, I’ll post it here.

Has any recent experimentation been done with supporting >1MB for MBRC?
Many moons ago, on a now dead & buried Oracle port, we raised the MBRC limit to 4MB and saw real benefit for OLAP/DSS/DW work that hoovered up large chunks of data. Given the advances in the h/w since then, this might be worth revisiting.

They aren’t completely OLTP, there’s some amount of batching.

Some FTS (and Index FFS) happen due to purposeful trade-offs on whether an index is there. Some issues also happen by accident or functional creep.

So, your test is a little bit applicable to OLTP too, and thank you for it, and thanks to Oracle for making the best of odd situations by default (absent bugs, of course).

>> It would be interesting to observe the impact of the back-end RAID (or ASM stripe size) on this test.

What would be interesting about it?
What metrics would you want to observe?
What would you expect to happen?

I don’t think it is any secret that when reading a significant amount of data (e.g FTS) that larger I/Os are more efficient. MBRC exists for this exact reason. Unfortunately there are many layers that I/Os can be fragmented before the I/O actually gets to the physical disk. Sometimes they are reassembled at the storage level, but not always. This doesn’t present a problem in itself per se, but it does lower the efficiency of each physical disk. Some storage also uses read-ahead/prefetch algorithms to accelerate such scans.

>> let’s not forget that this only applies to full-scan reads

I don’t think anyone is forgetting. I clearly stated this experiment was run with 100% physical I/O and a FTS. I would hope that neither of these would be present in an OLTP database. This is most applicable to a DSS workload (partition scans) where large reads are common.

>> the Oracle database can decide the optimal MBRC no matter what the blocksize, demonstrating there is no advantage to a larger (or even smaller) blocksize in this case.

It would be interesting to observe the impact of the back-end RAID (or ASM stripe size) on this test.

Also, let’s not forget that this only applies to full-scan reads, and MBRC will not help many OLTP systems.

My test is valid as pointed out by Vlad: the test is not about direct vs. cached reads. I specifically mention in my test case that I am forcing 100% physical reads. This is by intent. The point of this experiment is that it is not the block size that matters, rather the I/O size. You can do the experiment in 10g and not use direct reads, and the same observations can be made. Now, since 11g did introduce the serial direct read, the results should not be compared between versions, but the same behavior can still be observed. It just falls under a different event name.

If you set db_file_multiblock_read_count=0 and hit the bug, what normally would be a multi-block read (FTS/FFS) will be 1 block reads and thus a “db file sequential read”. In this case one will never see a “db file scatter read” because only 1 block is ever read. Give it a try and I think you will see what I mean. Maybe I was unclear by using 1 block and multi-block read in relation to each other.