The socket 6521 cannot be active on "apollo", so
you'll either have to take the TNS Listener down along with the instance or
restart the TNS Listener so that it is not listening on that socket after taking
the instance down. Taking the entire "apollo" machine down is another way
to accomplish this... :-)
It seems reasonable that the TNS Listener should
have functionality to fail immediately (or there should be a configurable
timeout) with some kind of error message if the desired database instance isn't
available, but it doesn't seem to work that way.
The "listener.ora" parameter
CONNECT_TIMEOUT_<lsnr-name> seems like it should be a good candidate for
this, but instead it seems to be a timer in the TNS Listener that starts
when a connection request first starts and ends when connection is
established. In other words, it is a protection mechanism against slow
clients or slow WANs tying up the TNS Listener process on each connection
attempt, establishing an upper-limit in which to completely establish a
connection. The default value of "0" seconds
means "indefinite". Unfortunately, this all doesn't seem to
translate into functionality where the TNS Listener process "times
itself out" if it can't establish the connection within a certain period,
oddly enough...
C'est la vie...
|
Title: tnsnames and sqlnet connectivity question
- tnsnames and sqlnet connectivity question Jamadagni, Rajendra
- Tim Gorman