Re: database monitoring tools - what is your short list of requirements?
- From: Jonathan Intner <jsidba@xxxxxxxxx>
- To: jkstill@xxxxxxxxx
- Date: Thu, 2 Apr 2009 17:24:33 -0400
Hi Jared, et al:
One more "what" comment:
Assuming auditing is enabled, alert on outlying behavior, for example,
XX user login failures where XX might be somewhere between 5 and 15 (you
might not want to lock SYSTEM after 10 failures, but you might want to know
they're happening).
[Note that there are a number of activities that warrant auditing...here's a
good paper, http://www.securityfocus.com/infocus/1689 from Pete Finnegan
that includes a reference to a script to consider using (available here:
http://www.petefinnigan.com/papers/audit.sql).]
Jonathan
On Thu, Apr 2, 2009 at 1:04 PM, Jared Still <jkstill@xxxxxxxxx> wrote:
> 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:
