Is there a SQL Plugin

[Paul L. Allen]

Andreas Ericsson writes: 

> Trivia time. :)

Trivia can be fun. 

> Paul L. Allen wrote:
>> Daniel Benoy writes: 
>> 
>>> SQL is just a Database language..
>>  
>> 
>> True.
> 
> SQL = Structured Query Language. It's connected with databases only by 
> coincidense, just like any UNIX OS could have apps written in Pascal 
> rather than C.

Do you happen to know of anything that isn't effectively a database that
accepts SQL queries?  I don't (but I admit I don't know everything).  I
have to say that I find it difficult to conceive of doing left and right
joins, for example, on something that wasn't effectively a database or
had a mode of operation in which it was effectively acting as a database.
I could talk to the postman in SQL, but I doubt he'd understand me or
give me an answer if he did. 

>> Not entirely true.  Each database has its own proprietary extensions.  
>> That said, I cannot conceive of any *sane* system where a plugin would
>> need to check the functioning of those proprietary features rather than
>> performing a simpler check of access to a particular table or record.
> 
> There's also ANSI SQL. Most (all?) RDBM's servers implement a superset of 
> the required parts of the language,

I expect that some of them don't implment all the required parts, or
implement some of the required parts incorrectly.  I would guess that
most of them claim to implement all the required parts and try to do so
even if they don't.  MySQL lists a number of ways in which it departs
from ANSI (but not whether those departures are from required or optional
parts) but it can be started up with --ansi if that matters to you. 

Even so, I cannot imagine any *sane* system where a plugin needs to
check anything but a minimal subset of the required parts of ANSI SQL.
Can you connect?  Can you select database X?  Can you pull record Y
from table Z and get the expected result?  Do you have at least W records
in table Z of database X?  There are many, many possible failure modes
in a database with many tables upon which complex queries are made but
checking for all those failure modes would be resource-intensive, even
if you could afford the time to analyse what all those failure modes might
be. 

I can conceive of some circumstances where you've been burned before
by a cow-orker doing something silly and the PHB requiring a very
complex SQL query to check that the same thing doesn't happen again (it
probably never will, and your cow-orker will find some other way of
breaking things that your current test doesn't spot).  I can conceive of
this check requiring the use of MySQL extensions that improve performance
because otherwise it would take so long that it would time out.  I just
don't think it's particularly sane to do it.  The most common problem
you're going to encounter is the database server not running at all for
some reason (system has been rebooted and the database isn't configured
to be started at boot; somebody has accidentally found a bug that causes
the database to crash; etc.)  Next most common is somebody accidentally
deleting a table or even a whole database.  If you need to use proprietary
extensions to do your checks then it's likely you're testing for a problem
that only occurs once in a blue moon. 

You could perhaps make a case for running checks invoking MySQL "CHECK
TABLE" but that would be slow and it's rare that tables get corrupted
except after a power failure (and rare even then), and it usually only
affects one or two tables out of hundreds, and checking all the tables
every few minutes just in case you've just recovered from a power failure
is going to consume a lot of resources.  In some cases, where one or two
tables are mission-critical, then you might have to check those.  For
us, power failures are rare; MySQL table corruption is rarer still (because
of ext3 journalling and RAIDed drives); and we have many customers using
MySQL for trivial things - in that case the customer does the monitoring.
If you're a bank and all your customer account details are in one gigantic
MySQL table then a regular "CHECK TABLE" can probably be justified, but
an rc.local "CHECK TABLE" on the mission-critical tables is probably
adequate for most people. 

>> Not entirely true.  Microsoft's SQL Server ripped off somebody else's
>> protocol - it's the Microsoft way, they never innovate, they either buy
>> somebody else's technology (if they have to) or rip it off (if they can
>> get away with it). 
> 
> That would be the tabular datastream protocol (TDS, as in FreeTDS) which 
> is also used by Sybase database servers.

I couldn't be bothered digging out the docs on FreeTDS, which I'm using
to monitor an MSSQL database.  I just remembered reading that TDS had
been ripped off by Microsoft from somebody else.  Microsoft rip off so
much it's hard to keep track of who they ripped it off from.  It's much
easier to keep track of what technology Microsoft has neither bought from
somebody else nor stolen from somebody else - there isn't any (even if
you count their aggressive business style as a technology, the MAFIA got
there first). 

-- 
Paul Allen
Softflare Support 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null