03-21-2013 11:05 PM - edited 03-21-2013 11:07 PM
I'm running HPUX 11.31 with SG 11.19, when a DB package fails over the DBA has to restart the listener before it will work.
I want the failover to be automatic, does anyone have any idea's as to what could be causing the problem?
When the DBA restarts the listener manually he does so from the oracle user account and he sources the oracle environment file, maybe this causes the listener to start differently compared to when it's run from SG?
BTW - I have checked the SG cluster logs and according to that the listener starts without any problems.
Any idea's would be appreciated.
03-22-2013 08:38 AM
Have you, or the DBA, checked the listener.log file to see what, if any erorrs are there?
When starting the listener from the SG package scripts, you should be doing something like:
su - oracle -c "lsnrctl start"
su - oracle -c ". <dbname>.env ; lsnrctl start"
If you are just starting the listener as root that is probably not a good idea.
How are you starting the databases? Are they coming up OK?
03-24-2013 03:10 PM
Thanks Patrick, I was thinking along those lines. I'm back in the office today so will have a look at the config and post back here.
03-24-2013 09:48 PM
I checked the config files and the listener is definately being started as oracle. The config looks the same as another cluster I look after and that does't have these issue's.
I've learnt more about this cluster today. I've found out that to get the failed over DB working the DBA has to firstly stop an OPENVIEW DB listener, start the failed over DB listener and then restart the OV DB listener. So there is obviously some kind of conflict between the 2 listeners. Both operate on different IP addresses but both use port 1521, I dont think this should cause a problem, do you? I've noticed that the listener being failed over doesn't have the IPC defined in the listener.ora file, this is used to indentify connections requests apparently, interestingly the OV listener file does have the IPC defined. Could this be causing me issues?
03-24-2013 11:47 PM
> Both operate on different IP addresses but both use port 1521, I dont think this should cause a problem, do you?
Are both listeners configured to use the respective IP addresses only?
If only one listener (let's say listener A) is configured to use a particular IP address only, that might cause the listeners to behave differently based on startup order.
If listener A is started first, it will bind to port 1521 on its configured IP address only, allowing listener B to bind to all the other IPs, and both listeners will start successfully.
But if listener B is started first, it will bind to *:1521, causing the port to be occupied on all IP addresses held by this host, and listener A will fail because it cannot get the IP/port combination it needs.
If the listeners are configured using hostnames instead of IP addresses, you should check what IP address(es) each hostname will map to.
I'm not an Oracle DBA, but I understand the IPC listener settings allow local processes to contact the database through the listener using Inter-Process Communication mechanisms, which can be faster than pushing the traffic through the network protocol stack. If the system also has an OpenView Server running on it, such an arrangement would make sense.
03-25-2013 06:46 AM
Anytime I've been in a situation where there were multiple Oracle listeners running on a server, we had each using its own port. One one server I used to manage we had an Oracle 8i listener on port 1521 and a 9i listener on port 1522.
Granted this was not in a cluster and only had a single production IP...