RE: db_file_multiblock_read_count and performance

Ryan,
a value of 128 is highly unrealistic. There are several reasons;
For example, as soon as one block in a range happens to be in the buffer
cache already,
It is not read in again. You will probably see differences in the estimated
CBO costs, though;
The only thing you do while playing with the parameter is to make CBO
*believe* that full table scans will be cheaper. In 9.2, enable system stats
gathering and run your jobs --
Then you will see the average number of blocks actually achieved by the
multi block reads...
 
Cheers,
Lex.
 
----------------------------------------------------------------
Tom Kyte Seminar: http://www.naturaljoin.nl/events/seminars.html
----------------------------------------------------------------
 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of ryan_gaffuri@xxxxxxxxxxx
Sent: Monday, December 06, 2004 18:21
To: Oracle-L@xxxxxxxxxxxxx
Subject: db_file_multiblock_read_count and performance

I have been testing this extensively over the last few months. I do a full
table scan with a db_file_multiblock_read_count = 1 and then one = 128( i
check the 10046 trace to verify i am getting this much) and I see absolutely
no difference whatsoever in response time. 
i am doing
select count(*)
from heap_table;
I have tested this on windows xp, solaris, with EMC, netapp, and regular old
cheap off the shelf hard drives. I have tested it in 8.1.7, 9.0,9.1,9.2.
has anyone see a response time improvement from this parameter anywhere? 
--
http://www.freelists.org/webpage/oracle-l



--
http://www.freelists.org/webpage/oracle-l

Other related posts: