Re: Performance metrics

      It's very tricky, and besides I have had innumerable cases of panic because all of a sudden (after a DB upgrade) some daily batch programs were taking 8 or 10 hours instead of the usual 5 ... Except that on further inquiry the initial 5 would have been 2 (and would have remained 2) had the programs been better coded. Poor programs are usually the least resilient ones, and the first ones to reveal that the new-feature-that-automagically-fixes-poor-programming-practices just happens not to be completely bullet-proof and in some cases makes things worse. And you can be sure that everyone will notice these cases, even if there is an improvement in 60% of cases and no change in 39%.

"When things start to go wrong" should rather read "when things start to go worse", because assuming that your base-line is clean is hugely optimistic.

There is something that you should collect, although it may not be easy: whenever a system is designed, it is based on assumptions about traffic, volumes, etc. Unfortunately for the hard-core DBA, it's not technical assumptions about I/Os or number of queries - rather, assumptions about a number of simultaneous users, number of orders per day, this kind of thing. Collect the actual value. Check how far you are from assumed limits. If one day the original assumptions are proved wrong, it will be mightily helpful to argue that the problem is in the architecture and that it is unlikely that you will find a magic recipe in a Metalink note or that Oracle Support can do much.

HTH,

-- 
Stephane Faroult
RoughSea Ltd <http://www.roughsea.com>
Konagora <http://www.konagora.com>
RoughSea Channel on Youtube <http://www.youtube.com/user/roughsealtd>



On 04/11/2012 08:34 PM, Martin Berger wrote:


> Hi,

>

> for me it seams there was a dangerous shortcut between [applications]

> performance and [database] indicators.

> Unfortunately there is no default path for this shortcut. You will

> have to find your own.

> This can be somehow tricky, but as a simple start you have to find the

> main contributor of DB time to your application.

> You can then monitor these contributors - if they increase

> dramatically in amount or time, it will become dangerous.

>

> Another method is to check for the appearance of 'new' waits - this

> can also be a sign of an unwanted change within your system.

>

> sorry, no simple answer; such as the question also is not simple :-(

>

> hth

>   Martin

>

>

> On Wed, Apr 11, 2012 at 18:17, Orlando L<oralrnr_at_gmail.com>  wrote:

>> Hi List

>> We have been asked to come up with key performance indicators for the

>> databases running in our company. The idea is to identify when things start

>> to go wrong. Can you please share the methods that are used for such

>> purposes.

> --

> http://www.freelists.org/webpage/oracle-l

>

>

>




--
http://www.freelists.org/webpage/oracle-l