Re: database monitoring tools - what is your short list of requirements?
- From: Jared Still <jkstill@xxxxxxxxx>
- To: daniel.fink@xxxxxxxxxxxxxx
- Date: Thu, 2 Apr 2009 10:04:45 -0700
On Thu, Apr 2, 2009 at 8:32 AM, Daniel Fink <daniel.fink@xxxxxxxxxxxxxx>wrote:
> I really don't care what language the core functionality is written
> in...as long as it works and is not too much of a resource consumer. It's
> when I want to add custom monitoring that I want to use the lowest common
> language. If a new DBA comes onboard and does not know tcl/perl/java, it
> will take time for them to learn the language and be able to support the
> customizations/enhance the tool.
>
>
It seems the thread has now morphed into a 'how' not 'what' thread.
Dan, you do make a good point about DBA's knowing SQL and MAYBE pl/sql.
( too many DBA's don't know even basic PL/SQL)
I agree with Rich however that Oracle ( or anything ) shouldn't be used to
monitor
itself, at least from a DBA monitoring perspective.
PMON/SMON may check up on each other, but that is for internal consistency.
Much of the database monitoring should be done external to the database.
eg. I like my monitor to be able to report that they could not connect to
the database.
Monitors based on the database software itself are prone to going silent
at a critical moment.
That said, the method I use to determine how I will monitor some aspect
of a database goes something like this:
simple - shell script calling sqlplus and running a script
not so simple - perl script, which may be called by a shell script
The shell script is often a driver for calling a SQL/Perl script
for multiple databases, and setting up the environment if necessary.
Perl is my language of choice for a number of reasons:
Huge library
Does nearly anything I want.
No, make that everything I've ever wanted it to do.
Far, far from bleeding, or even leading edge. ie. stable
Easily installed.
Installable on Windows if needed.
There are other scripting languages available, but for various reasons
they aren't really competitors for Perl in this space.
As for DBA's not knowing Perl - well, they should learn.
( Or some language that has been standardized on
in a particular environment. )
It doesn't mean that a DBA has to dive deep into the language.
A DBA should be comfortable with the basics of PL/SQL,
as well as the basics of Perl. Learing the basics of Perl,
or any other language of choice, is probably simpler than
learning how to setup custom monitors in most commercial
monitor software.
Just as many (including me, though I avoid it) have learned to
use vbscript on windows, Perl is a very robust DBA tool.
Shell script just doesn't cut it for many needs.
Shell (ksh , bash) are fairly powerful, but too many kludgy workarounds
needed for manipulating data obtained from a database.
As for scheduling, I rely on cron, both on *nix and Windows.
I have considered setting up a db to use the dba scheduler, as it is quite
a bit more robust than cron.
That database would be monitored by a job from cron though, so I
know if it isn't working.
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
