Re: Performance metrics
- From: Stephane Faroult <sfaroult@xxxxxxxxxxxx>
- To: martin.a.berger@xxxxxxxxx
- Date: Thu, 12 Apr 2012 10:01:37 +0200
+1 to what Martin said.
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@xxxxxxxxx> 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.
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
