starting listener running on remote server using script

[Geoff Wild]

As Brian mentioned - why not put the shutdown commands in a script on the remote system - then remsh and execute that script instead...

We do something similiar for our backups. bcv splitting and mounting on backup server.

Rgds...Geoff

[Kevin Batter_4]

little bit more info

as per suggestions I have created a script on the prod server that the DR server invokes

To test it I used lsnrctl status - this worked using both

su - oracle -c "lsnrctl status"

and adding oracle variables to begining of script and running su oracle -c "lsnrctl status"

So the feeling here is that it is an issue with running lsnrctl start - got a run of the script coming up this weekend and have gone for the adding variables to script and running su oracle -c lsnrctl start

Will let you know if this makes a difference

[Fred Ruffet]

Did you add patches to OS recently, or changed HP-UX version ? I faced a similar problem upgrading to a more recent version, and found this explenation on an HP site (applicable to versions since 11iv1.6) :

"remsh or rexec may appear hung when you execute certain remote commands, because it waits for the remote command to finish before exiting. This behavior can be changed by adding the -m option to the remsh and rexec lines in /etc/inetd.conf."

You could try to add -m option to remsh line in inetd.conf, restart inetd and try an unmodified version of your script.

Hope this helps,

Fred

[Brian Crabtree]

Why are you stopping the listener? The listener can continue to run while you split off the BCV's without a problem. If the shutdown and startup is working correctly, just use that, and leave the listener running.

Thanks,

Brian

[Kevin Batter_4]

Ok - ran the script as described and once again we had to kill the remsh from the DR server to the prod server that started the listener.

I attach a copy of the script we are using the
first part runs on DR server and invokes second part on Prod server,we will try the -m option on rexec/rlogin this coming weekend but in case there is something that we have missed in the scripts would appreciate any ideas/help

Thanks

[T G Manikandan]

Kevin,

Sorry i am from the beginning,

Did a normal remsh work properly

Did the lsnrctl start work from the local server.

[Geoff Wild · Accepted solution]

Just a thought for the listener, we specify the listener when we stop/start it like so:

remsh ${PRODUCTION_NODE} -n "/bin/su - oracle -c 'lsnrctl start listenerPROD'" | tee ${LOGFILE} >/dev/null 2>&1

Better yet, why not like this:

remsh ${PRODUCTION_NODE} -l oracle -n "lsnrctl start listenerPROD" | tee ${LOGFILE} >/dev/null 2>&1

Rgds...Geoff

[Kevin Batter_4]

TG - yes normal remsh work - earlier in the script we shutdown the Database and the listener using remsh.
The listener starts ok on the prod server it just does not return to the script on the DR server so the DR server script just hangs until we kill the remsh process that is starting the listener up.
Once that is done the script continues on the DR server completing ok

[Volker Borowski]

Hi,

so then do not care about the listener. It has absolutly nothing to do with the datafiles, so to get a consistent copy, it is not needed to stop the listener.
Just shut down the database, do the split and let the listener up and running.
Beside this, to do the login as oracle user as Geoff suggested would be best.

Keep in mind, that you do not need to use any shell at all to re-cycle the listener, since the listener can be controlled remotely (if it is up and runnning) without any shell access .
"lsnrctl" and a proper listener.ora is all you need on a client which should control the target listener [This is why you should configure a password for the listener(!)].

So the last way out would be to do the copy via remsh and re-cycle the listener via network without the shell in case you just want to bounce the listener for whatever reason.

Hope this helps
Volker