Re: Oracle slowed down

Brian Peasland wrote:
> > I think they did. If you look at Buffer Cache Size Advice, you'll
> > notice they say "Relative Change in Physical Reads."
>
> Even this is still akin to the BCHR. Increasing or decreasing your
> buffer cache will make changes to the physical reads required to satisfy
> your "normal" workload. But is this really that different than tuning by
> the BCHR? So I decreased by physical reads by 10%. Is that good? It may
> or may not be. In some cases, I still have poorly written SQL which
> needs to be tuned. Tuning that SQL can reduce the physical reads as
> well. Sizing the buffer cache to reduce the physical reads, is the same
> (in my book) as sizing the buffer cache to increase the BCHR.

I wouldn't say that, because you can iteratively tune physical reads and bad SQL as you find it. Now it may be better methodology to tune logical reads anyways, as Milsap says, since the physical reads implies obsolete JBOD technology, and perhaps some myths. In spite of that, it seems useful to me to use the bc advice as a gross measure to get the buffer sizing into the ballpark, _then_ use a more advanced tuning methodology, preferably incorporating knowledge of the app. The BCHR seems less useful for that, as it can only even try to be useful in a stable system, and suffers from the issues previously posted in this thread there and in a pre-ballpark system.

I also thought the advice was simply BCHR, but I vaguely recall Jonathan posted it was more subtle than that, though I missed where he explained why.

jg

-- 
@home.com is bogus.
http://elonka.com/kryptos/