Re: Grid Control - opinions please
- From: "Jared Still" <jkstill@xxxxxxxxx>
- To: bob_murching@xxxxxxxxx
- Date: Thu, 6 Apr 2006 08:43:06 -0700
Personally, I've already dismissed GC for its external
monitoring capabilities.
We have NetIQ App Mgr for that, which has a proven track
record. Plus, we've already paid for it. :)
Jared
On 4/6/06, Bob Murching <bob_murching@xxxxxxxxx> wrote:
>
> What Grid Control facilitates is enterprise monitoring and reporting, the
> broader question is, how important is that to you? In this future SOA world
> that everyone is blindly rushing into, servers and databases are mere
> components of an overarching application service that requires a somewhat
> different kind of monitoring or reporting. Or so the argument goes. GC is
> positioning itself to be the platform for providing that service-oriented
> monitoring, reporting and [potentially] administration.
>
> Particularly with R2 and the various BigIP/MSSQL/Cisco/NetApp monitoring
> capabilities that are coming to light, Grid Control is trying to become less
> of a DBA tool and more of an enterprise service management console of
> sorts. Unfortunately, all that does is leave DBAs high and dry, while
> evolving OEM into the sort of thing that Gartner praises but in reality adds
> little value for many shops. Such is the way of IT, though. Accept it
> for what it is and make the most use of what [little] it offers to DBAs...
> that's my advice.
>
> ------------------------------
> *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> wrote:
> >
> > 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
> notifications.
>
> 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
>
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
