RE: Grid Control - opinions please

  • From: "Baumgartel, Paul" <paul.baumgartel@xxxxxxxxxxxxxxxxx>
  • To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 6 Apr 2006 10:49:05 -0400

Jared, I couldn't agree more.  I stick to SQL scripts and SQL*Plus to do 99% of 
my work.  Reliable, effective, keeps my knowledge current. 

Paul Baumgartel 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On 
Behalf Of Jared Still
Sent: Thursday, April 06, 2006 10:44 AM
To: Jason Heinrich
Cc: Oracle-L Freelists
Subject: Re: Grid Control - opinions please

Comments below:

On 4/6/06, Jason Heinrich < jheinrich@xxxxxxxx <mailto:jheinrich@xxxxxxxx> > 

That said, things aren't all sunshine and roses.  Running in a browser does
limit you to only working on one target at a time, though you could open
multiple browser tabs to get around this.  Certain targets have a bad habit 
of going into "Status pending" or "Metric collection error" status for no
apparent reason; and I'm having the same issue as Jeffrey Beckstrom, where
GC won't send me notification emails, even though everything appears to be 
setup properly.  Finally, I haven't found a way to display a list of
sessions on a database without using the Diagnostics Pack.

I can't help myself here, as there are now multiple complaints about the 

The Perl/shell/SQLPlus/PLSQL daemons and/or scripts run from cron 
have for several years been monitoring databases that I am in responsible for.
(Mostly  Perl)

Among the things monitored: 

* database uptime.  during (configurable per each db) uptime hours, the 
 oncall DBA is paged if a database is unresponsive.  If it happens during
 non-critical hours, the page is delayed until a configurable number of 
 connection attempts have failed in succession.  This avoids waking the 
 DBA up (me) if the problem corrects itself.

* space - email a report every morning with space issues. Objects
   appear in the report if they do not have enough space to add 
   more extents (5 I think).  Accounts for autoextend files.

* Windows services.  Windows has the nasty habit of sometimes failing
  to start a service on bootup. This could be a timeout issue, as there is 
  a lot happening at bootup.  A Perl service on another windows box 
  checks certain remote services, restarts them if they are down and
  pages the DBA.

* response time monitoring.  No paging, just charts generated showing 
  average response times from the database perspective.  Based on
  Statspack and YAPP.

* alert log monitoring.  check for errors in the alert.log.  Which errors
 to check and which to ignore is configurable via regex. Runs as a 
 daemon on linux/unix, and a service on Windows.
 This has been in use and working with very few problems since 1998
 on Unix, 2002 on Windows.  It does work better on unix though.

No doubt many DBA's have reliable home grown scripts and processes 
for monitoring and managing databases.

A GUI is no substitute for knowing how the database works.

The scripting approach has an advantage that OEM/GC or any other
tool has:  you are not dependent on a vendo (Oracle or anyone else) 
to fix or support their tool so you can do your job.

You can create tools to do exactly what you need.  If your needs change
you can modify them. When they break, you can fix them.

If you made it this far, thanks for reading all this. 

And perhaps you can understand the apprehension felt by many when attempting
to use some of the 'time saving' tools, and the reluctance to give up tried
and true methods.

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist 

Please access the attached hyperlink for an important electronic communications 

Other related posts: