Inconsistent IO Wait Time

Question

I'm trying to comprehend why oracle seems to more efficiently table scan a table when it has more rows than when it has less.
I have run a bunch of queries against the database, and I have tracked their wait events stats.
And it seems that this ratio:
ReacorsPerWait = #records/ wait_time,
where db_file_scattered_read is the most significant wait event by a lot
This Ratio simply Increases on and on, although the rate of increase grows eventually slower.
Namely, this ratio is practically the same when the relatio changes from 25 Million tuples to 125 Million tuples. But
before reaching that ratio threshold, the ratio increases quite significantly from test to test.
(From 0.2 Million to 1 million, to 5 million and to 25 Million...
It increases way too fast. I get changes in rate of more than 40%)
I just cannot make any sense of this performance change, If the number of records is increasing by 5 the IO time should also be increasing by 5.
What I have tried to do to fix this at some constant rate was: set the db_multiblock_read_count at some constant value. I set it up to like 10 MB. (10* 1024 KB / 8 KB)
But the results are the same, with or without a fixed multiblock read count, Oracle IOs faster when the relation is bigger. What is the cause of this? Any Ideas.
Another interesting thing is that the Cache Hit Ratio is reducing as the IO speed is increasing.
But the number of physical reads increase proportionately (times 5). I thought that this migh be explained because Oracle might Use larger Multi Block Reads when the relation was larger - or something like that.
But now I know that that cannot be the reason.
(By the way: this change in rate could be explained - partially - in the tests from 0.2Million to 1 million due to other wait time like reading control file, which is significant for small examples. But from 1 Million oward, approximately 99% of the wait time is doing the db file scattered read)
Edited by: sono99 on Nov 4, 2009 4:22 AM
Edited by: sono99 on Nov 4, 2009 4:30 AM
Edited by: sono99 on Nov 4, 2009 4:32 AM

Answer 1

sono99 wrote:
HI, thank you for trying to help.
"It's likely that measurements also vary with row size and not just row count ... not to mention half a dozen other features.
There are a couple of obvious possibilities:"I think that are not likely to be reason of the improvement in IO performance. Sure, I am not saying that standard deviation of row size is 0, but I'd say whichever the STD for the row size is, it will be pretty small.
To begin with, the table is populated with data generated by a home coocked program.
The table has like 6 collumns of integer type, none of them has null values.
If you ask a generic question you get generic answers.
Your original posting was about "the database", not about "a specific table created on a single disc for test purposes".
Have you tried cloning the table several times and seeing if the results are consistent across all clones ? There are several possible causes of variation in your case, for example has part of your table has ended up on a less fragmented part of the disc, or on the outer edge of the disc, so that the multiblock reads are more effective, or the disk-level track caching is more effective.
All sorts of strange side effects can appear when you create single user tests on small machines, and you have to be careful to consider the effects of multi-user activity on "realistic" system when constructing tests. It can be quite difficult to identify the points where a test is not properly representative of the mechanism you are trying to investigate.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan