Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: sequential read on full-table scan?
Steve,
That is exactly why Oracle did not want to put the code to check for collisions every time MBR disk I/O read is happening.
The only time this is happening is direct path reads where it is nothing to do with the cache but rather PGA removing the collisions alltogether.
This is somehow similar to some RAC cache fusion
problems.
Just imagine if the block is dirty in the cache while
you are getting the same block with MBR from the disk.
What is Oracle going to do?
Oracle should then put something similar as the RAC
code to manage this situation, downgrade locks, ....
who knows what :)
Or what if the table is said to be cached while not
all blocks still put into the cache? Or million other
situations that nobody knows.
And not to mention their C code.
They have a lot of bugs to fix in 9.2.0.6 anyway :)
To not mention that you did not pay for RAC :)
Joking of course, but it looks that it is a big trade off for Oracle.
I am using much more parallel 2 to do the FTS for the
driving table, because it is so much faster while
hopefuly you are not going to kill your "good" disk
I/O subsystem with just parallel 2.
Also, it is ideal for history data you do not want to
be cached anyway.
I used to work with 130G buffer cache and the
difference in FTS with direct path reads (parallel)and
without were drastic.
Regards,
Zoran
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 25 2005 - 03:28:35 CDT
![]() |
![]() |