lsnrctl command stops listener on another server

[Dave Meador_1]

lsnrctl appears to have the abiliby to issue commands to servers other then the one that the command is actually run on. How is this being facilitated? Is the fact that we have service guard running causing this? We have 2 HP-UX clusters running service guard, one is production and the second is a new cluster being setup for DR.

We want to avoid lsnrctl commands issued on the new DR cluster from being executed on the real production cluster until we implement the new cluster at our DR site.

Thanks!

[Brian Crabtree · Accepted solution]

This happens because the listener.ora command is pointing to the second server. Your best options are to create a different listneer name for your DRP system, or set passwords on your listeners that are different for DRP and production. This will make the listener ask for the password before stopping, and should keep the production listener from being stopped by the DRP process.

Brian

[Dave Meador_1]

Thanks Brian, That looks like the problem, I made the wrong assumption that TNSNAMES was used, but it was the listener.ora file. A password on the listener is a great idea! Best Regards, Dave.