Re: Performance-Monitoring

Mark D Powell wrote:
> Uwe, Look at the statspack feature. If you compare a recent statspack
> to a baseline statspack then the reports can sometimes be used to
> identify potential problems.
>
> Frank has a very good point about customer complaints. No matter what
> the statistics look like whatever the customer complaigns about is most
> like what should be given priority. Also customer complaints do not
> always reach the DBA so devoting time to searching for poorly
> performing tasks and just tuning them can pay benefits.
>
> IMHO -- Mark D Powell --
>

OK - not exactly what I meant, but equally true.

I was trying to get the point across that tuning should not be done for the sake of tuning. It must have a purpose, which should be the gains from a defined starting point to a defined end point.
Especially in the definition part I seldom get valid responses. Usually something like "it's (un)acceptable" without any numbers. No numbers, no gain, no game.

There's one other aspect, though. When going over code (either because the system is in maintenance state, or because it's being (re-)designed, or because the hardware is changed) test and see if gains can be found in the high-impact queries. Mind you: impact is (time * # of executions); gaining 0.2 secs on a statement that is executed millions of times during a reporting cycle brings more than one report taking 5 minutes, instead of 15.

There are no "performance values": your database is unique! (this smells like BCHR tuning: 65% BCHR is bad, Bad, BAD!)

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...