Re: Using a different file for listener startup then listener.ora?

the evil twin of Kendall Willets (TV DBA) wrote:
> One interesting side effect of having a universal listener.ora is that
> one can use lsnrctl to operate on listeners remotely. lsnrctl uses

D'Oh, after thinking of that I remembered another undocumented feature of lsnrctl, which is that if your TNS_ADMIN is messed up and it can't look up the listener name in listener.ora, you can use the SID from tnsnames.ora and it will connect to that port and talk to whatever listener is there. So even without listener.ora, you can talk to all the SIDs in your namespace from lsnrctl, eg

lsnrctl> status host1_sid
<connects to host1.port and status report comes out> lsnrctl> status host2_sid
<connects to host2..>
....etc....

I used to think that was the way lsnrctl worked, eg

lsnrctl stop listener1
<error - no such listener>
lsnrctl stop SID1
<successful>

until I figured out that our sqlnet config was somewhat dysfunctional.

In any case that's a useful tip if you feel the need to check lots of listeners on different hosts. Sure beats tnsping. Received on Fri Sep 19 1997 - 00:00:00 CDT