"McKay-Mills, Simon" <[EMAIL PROTECTED]> writes: > I don't really want to install Oracle on it (in order to get the > perl oracle module to work) or to get sqlnet or tnsping installed.
It seems to me you're going to be pretty hard-pressed to directly test a database connection if you don't install any software able to access it. :-) Unfortunately, I don't think it's even a matter of your willingness or lack thereof---I don't think you're ever going to be able to directly test Oracle from that box because I don't believe Oracle provides Linux/Sparc libraries at all. For MS SQL, you could probably use the FreeTDS library and DBD::Sybase, at least enough to check responsiveness. > 1. I am a bit confused on how to get the msql-mysql.monitor to > work. The actual file infers putting --mode hostname but how does it > fit into a mon.cfg file??? Errrr, that monitor has nothing to do with MS SQL. It's for mSQL or MySQL (hence the name), neither of which are in any way MS SQL compatible. But yes, you just tack the parameters onto the definition of the monitor. > 2. The Oracle side has me stumped. The sqlconn.monitor that comes > with mon seems to want Oracle installed locally - any way around > this?? Not for doing direct testing---you have to have Oracle libraries, etc. None of which, I think, exist for Linux/Sparc, so you're pretty doubly screwed on that front. I see three possible options, in descending order of how I would approach things: * SNMP monitoring of the databases Oracle, and I would presume MS SQL, has some sort of ability to do SNMP. It might be possible to restate your monitoring needs in terms of SNMP tests, rather than direct database-level connections. Some DBAs would likely even argue for it on your behalf, as some of the ones I've known wouldn't want people starting up unnecessary connections on their databases every five minutes or so. * Autonomous monitors & traps Write a daemon to reside on hosts that are already able to connect to the databases in question that maintains a persistent connection to the servers, periodically doing a "ping" or a simple select to make sure it responds. If the DB doesn't respond, generate a mon trap. * Proxy connections On boxes that are already setup for doing connections to the databases, install a reasonably-late-model copy of DBI, which will include DBI::Proxy---you could then connect from your mon host to the machine running a proxy, and then connect from there to your target server. This would presumably work for both Oracle and MS SQL. Making the monitor truly rock solid requires some care---you may need to figure out some way to tell the difference between the proxy going down and the database itself being down, etc. > 4. Is there a list of services that can be called from within the > mon.cfg? I guess it must be somewhere but I haven't come across it > yet... You get to name services. The name is intended to be for your consumption, so pages, etc. are easily recognizable for what failed. Mike.
