RE: monitoring multiple databases using PL/SQL -- follow-up question

Point 3 sounds correct..

Make sure that you also *monitor the monitor*!! Even if you just set up AT job or something that runs from a DBA desktop every 10-20 minutes, connects to the instance and "select 'OK' from dual;" to test the connection.. If it fails, flag an error through something like "net send" or email..

HTH Mark

 Mark Leith             | T: +44 (0)1905 330 281
 Sales & Marketing      | F: +44 (0)870 127 5283
 Cool Tools UK Ltd      | E: mark_at_cool-tools.co.uk
===================================================
           http://www.cool-tools.co.uk
       Maximising throughput & performance

-----Original Message-----
dmeng_at_focal.com
Sent: 24 April 2002 23:04
To: Multiple recipients of list ORACLE-L question

Thanks all who replied to my E-mail.
Right now I am still leaning toward having a centralized monitoring script running in a admin database because -
1. Ease of administration
2. We don't need anything fancy, don't need application level monitorin, so the requirements for different databases are similar. 3. If we use PL/SQL jobs and monitoring tables then all of our scripts can be backed up as part of the database backup. So if anything happens to the monitoring server/db all we have to do is recovering the database. We can even restore the monitoring database to another server if we need to. I am not certain if point 3 is correct so any thoughts on this?

Dennis Meng
Database Administrator
Focal Communications Corp.

                    Stephane
                    Faroult              To:     Multiple recipients of list
ORACLE-L <ORACLE-L_at_fatcity.com>
                    <sfaroult_at_ori        cc:
                    ole.com>             Subject:     Re: monitoring
multiple databases using PL/SQL
                    Sent by:
                    root_at_fatcity.
                    com


                    04/23/02
                    08:03 PM
                    Please
                    respond to
                    ORACLE-L

Ypu may find the following paper of interest:

   http://www.oriole.com/papers/monitor.html

A few years old, but sits somewhere in the middle as Chris suggests. And you can use all of his scripts :-).

"Grabowy, Chris" wrote:
>
> Dennis,
>
> True, but you should also consider...
>
> "In a decentralized configuration, the monitoring software or scripts
reside
> with the database. This complicates maintenance, but allows for higher
> monitoring availability."
>
> I believe that your better off somewhere in the middle.
>
> You can host a set of PL/SQL procs in a "monitoring" schema on each
database
> server to check the basics of the database, and report back to you. In
this
> configuration, you can enhance and add features to the development
version,
> and make sure it works, before updating all the databases. Du'oh!!
> Configuration Management!!!
>
> And then you can host specific "are you up/bogus login" scripts on a
central
> host.
>
> Generally, your Oracle database stays up...since it's not SQL
> Server...du'oh!!! The majority of the database problems are in the
> database, ie. maxextents, no space, performance, blah, blah...there is a
> list in my paper.
>
> Don't forget to collect all this monitoring data in some table(s), as it
> will become useful.
>
> And be sure to CC your boss on all the benefits your monitoring services
> provide you. Hopefully, some funding will eventually be thrown your way
to
> get a decent monitoring product.
>
> Also, recently I saw a demo of a monitoring product called AutoDBA. It
is
> very slick, almost like having a junior DBA doing all the boring,
> monitoring, dirty work. Except it doesn't get your coffee for you...or
wash
> your car...or...
>
> HTH.
>
> Chris Grabowy
>
> DISCLAIMER: I am not in any way associated with the makers of AutoDBA.
My
> paper also includes a list of other monitoring products.
>
> -----Original Message-----
> Sent: Tuesday, April 23, 2002 1:53 PM
> To: Multiple recipients of list ORACLE-L
>
> >From 'Oracle Database Monitoring for the Beginner' (pdf) - Chris Grabowy
>
> "In a centralized configuration, the monitoring software scripts reside
on
> one server. This obviously makes maintenance easier, but if the hosting
> server fails then there is no (more) monitoring of the databases"
>
> regards
> Madhu
>
> >From: dmeng_at_focal.com
> >Reply-To: ORACLE-L_at_fatcity.com
> >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >Subject: monitoring multiple databases using PL/SQL
> >Date: Tue, 23 Apr 2002 08:00:33 -0800
> >
> >Greetings -
> >I am planning to centralize our Oracle monitoring process by using one
> >PL/SQL procedure to query database extents, invalid objects, alert logs
etc
> >through database links. I wonder if anybody has done it before and if
there
> >is any cons with it. The pros would be ease of administration, ease of
> >standardization etc.
> >
> >TIA
> >
> >Dennis
> >

--
Regards,

Stephane Faroult
Oriole Software
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Stephane Faroult
  INET: sfaroult_at_oriole.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




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

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mark Leith
  INET: mark_at_cool-tools.co.uk

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).