db_file_multiblock_read_count causing full scans to take longer?
- From: "Don Seiler" <don@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 19 Dec 2006 12:44:05 -0600
After having it set in our dev instances for a week, I raised our
db_file_multiblock_read_count in production from 16 to 128 (based on
documented 10046 traces). After getting tickets about certain
operations being slow, I identified a select query against our NOTES
table as doing a full scan, which it did previously as well. However
the full scan now takes 133 seconds, as opposed to 8-10 seconds with
db_file_multiblock_read_count of 16 or 32.
Granted, there needs to be some query tuning done (or a crutch index
in the meantime) so that we aren't doing this full scan, but I thought
that db_file_multiblock_read_count would make full scans take less
time, if anything. Autotraces and query plans show similar numbers,
as far as I can tell.
Any thoughts?
--
//www.freelists.org/webpage/oracle-l
Other related posts:
