Re: d/b health check

From: Peter Robson <pgro_at_bgs.ac.uk>
Date: Wed, 25 Aug 2004 14:01:50 +0100
Message-ID: <569934991.20040825140150@bgs.ac.uk>

LD> Can anyone point me to a good outline for a 'database health-check'.  I.e.
LD> is it best to base it on statspack/bstat/estat, some form of response time
LD> breakdown (I'm reading Cary's book at the moment) or something else
LD> entirely.

Ah, this is a great question!

I answer, because I have built an automated system for returning a 'database health quotient' via email every day. Management love it ...

This is how it works...

There are something like 150 exception alerts generated every night by batch jobs, checking all manner of parameters on Oracle, both data and metadata. Each test provide a FAIL numeric, as against a POPULATION numeric, eg the total number of distinct conditions checked for compliance.

At the end of all the batch runs, a total FAIL count is computed as a percentage of the total population from which the fails are obtained - QED a percentage - your 'database health check'!

Of course, it is utterly meaningless in isolation of a clear and objective understanding of the parameters being measured. So any such quotient will be highly specific. If not, it may mask something that is critically important!

But is ain't half cool to say that the database health quotient improved from 97.35% to 98.21% last night!!

Bottom line - 'caveat emptor'.

peter
edinburgh
..............

mailto:pgro_at_bgs.ac.uk

This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. However, the information contained in this e-mail may subsequently be subject to public disclosure under the Freedom of Information Act 2000 and, unless the information is legally exempt from disclosure, the confidentially of this e-mail and your reply cannot be guaranteed. If this message was not intended for you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. http://www.bgs.ac.uk

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Received on Wed Aug 25 2004 - 07:58:00 CDT