| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> 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.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of ryan_gaffuri_at_comcast.net
Sent: Monday, December 06, 2004 18:21
To: Oracle-L_at_freelists.org
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
Received on Mon Dec 06 2004 - 11:49:39 CST
 |
 |