Re: How to use tnsping programmatically

From: Ruud de Koter <nobody_at_internet.org>
Date: Wed, 08 Apr 2009 22:54:14 +0200
Message-ID: <49dd0ef4$0$194$e4fe514c_at_news.xs4all.nl>



Hi Paolo,
>> You can call tnsping from a shell script or a program, but how often
>> are you planning on running this check?
>> How often were you running your last check that managment or the
>> network team asked you not to run?
>> There is generally no real need to continuously check to see if the
>> database is there.  If the database is not there you will know in
>> fairly short order when the phone calls start coming in.  From within
>> an application you can just check the return code on the connect
>> call.  If the connect fails you will get an error code and you can
>> pass this on to an alert system (feature) to provide the database down/
>> unreachable error information.

>
> Thanx for answering Mark,
>
> the need is to avoid attempting the connection if the Oracle instance
> appears to be unreachable. We're developing a panel pc app that has to
> connect to an Oracle server on demand (user touching screen and booking
> for canteen).
>
> Problem is that the Oracle server happens to be on the other side of the
> mountains (and this is for real, no joke) and we've been warned about
> lack of connectivity/bandwidth on this connection.

If the issue is actually in the network connection, tnsping seems a bit of an overkill. Why don't you use ping (or something like it) to ascertain the network connection is useable. I would assume the rest of the technology (listener, Oracle instance, OS) to be robust enough to risk the occasional error message.

>
> So, to make a long story short, what i'm trying to do is avoid
> connection (and users waiting for a timeout to occur in front of pc) if
> Oracle is not tnspingable...

When using ping there is no garantuee that you will have connectivity even milliseconds after your last succesful test. Others have already pointed this out for the tnsping approach. So all you 'll be doing is avoiding timeouts. If that's your goal, then simply testing the network connewction might work just as well.

Regards,

Ruud de Koter.
>
> Other ideas are welcome, of course :)
>

>> HTH -- Mark D Powell --

>
> Thanx again
> Paolo
Received on Wed Apr 08 2009 - 15:54:14 CDT

Original text of this message