Re: Got the darn buffer busy waits under control, at last!

An important point that is often overlooked, of course, is that the session exhibiting a problem is not necessarily the session causing the problem.

So doing something that SHOLD have no effect on the symptoms you are seeing MAY result in a change elsewhere that results in your symptoms disappearing.

For example a reduction in tablescanning in one program may result in a reduction in the number of buffer busy waits in another program. Or perhaps an improvement in progarm ONE makes it run faster, so program TWO starts five minutes earlier and program TWOB in a parallel stream starts running faster for no immediately obvious reason because it is no longer in contention with program TWO.

It is a defect (perhaps too strong a word) of the nice, clean, simple, strategy of tuning by bottlenecks that the bottleneck is sometimes easy to see, but the cause of the bottleneck is somewhere completely different. It's not magic, of course, but it is the point where you may have to change from a simple procedure to in-depth knowledge of Oracle, the application and the business.

--
Jonathan Lewis
http://www.jlcomp.demon.co.uk

Next Seminars
        UK            June / July
        Australia      July / August
http://www.jlcomp.demon.co.uk/seminar.html

Nuno Souto wrote in message
<3d0f0d8c$0$28009$afc38c87_at_news.optusnet.com.au>...



>That and the fact that some pre-identified SQL which caused prior

>problems now runs faster than before?  I mean: in the absence of any

>accurate application specific metrics (where are they, Peopleslop???),

>the only thing we can really do is keep an history of previously

>problematic SQL and re-run it after every change.

>