General
cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple Oracle listeners on ServiceGuard Cluster

SOLVED
Go to solution
Ken Polton
Occasional Contributor

Multiple Oracle listeners on ServiceGuard Cluster

Answers to a question raised June 29, 2001 - "Oracle with Service Guard" refer to having tnsnames.ora and listener.ora 'identical on both servers'...

The development (and production failover) node of our cluster has two SG packages with floating IP addresses supporting a couple of 8i databases, one with Apps 10.7 and the other with Apps 11i. Because the packages are self-contained, tnsnames.ora and listener.ora are in the relevant Oracle homes and a listener is started with the package.

Futhermore, a database for reporting purposes is kept unpackaged on the server and the listener is on the server's own IP address.

For some time, we have had to keep the all the listeners on different ports, as different IP addresses are insufficient to stop a listener developing a service handler for another database when it starts up (even though relevant listener.ora has no reference to it). Consequently the packaged listeners (or the unpackaged one, for that matter) fail to start. When the listener that has "poached" a foreign database is shut down, that database is left unreachable.

Oracle Support didn't seem to be too comfortable with the concept of 'floating IP addresses' when I raised this with them a couple of months back, so I thought I'd see if anybody familiar with ServiceGuard has experienced this probelm before I try them again.
5 REPLIES
Guy Dickson
Occasional Visitor

Re: Multiple Oracle listeners on ServiceGuard Cluster

Try using named listeners. Because each package has its own IP address you can use the same port, as it's the ip/port# that has to be unique. You get the package to start named listeners: lsnrctl start
You'll also have to ensure that all environments use the latest listener. We use this and it works really well, you only end up with one set of files to maintain, you can have multiple dbs being serviced by each named listener etc. etc. It's almost made for ServiceGuard
Ken Polton
Occasional Contributor

Re: Multiple Oracle listeners on ServiceGuard Cluster

Thanks, Guy.
I'm sorry I didn't mention it, but the listeners always have had unique names. What you say about a unique IP/port combination agrees with what we understood and Oracle expect... but we found we had to have the port unique, regardless of the IP address.

Neither did I say explicitly that the databases and Apps are at different revision levels to evaluate the most stable configuration for the production database; the listener is the version that is shipped with the rest of the Apps and RDBMS code.

We found that only one listener could develop a service handler for any one database and we would get errors saying "the" listener (actually a different one) was already running when we tried starting the correct one - because the wrong listener had developed a service handler when the database started up. If you have multiple listeners handling one database, I would be pleased to learn how.
linuxfan
Honored Contributor
Solution

Re: Multiple Oracle listeners on ServiceGuard Cluster

Hi Ken,

To keep things simple always use unique port numbers for different oracle instances. To configure multiple listeners for the same database(i assume this is for load balancing you have to set the MTS_MULTIPLE_LISTENERS = TRUE ) option. This is the extract from the Net8 Admin Guide.
/Begin Quote/
Listener Load Balancing
The listener load balancing feature allows you to distribute multiple incoming client sessions among several listeners. This feature helps to ensure that no single listener is overburdened. Periodically, each of the service handlers sends its load information to each listener that it is registered with. Thus, each listener knows how busy each of the handlers is and redirects incoming sessions to the least busy of those handlers.

Listener load balancing cannot be used in the following situations:

Prespawned dedicated server processes cannot use listener load balancing because a prespawned dedicated server process registers itself only with the listener that started it.
Oracle Parallel Servers have their own method of listener load balancing. For more information, refer to your Oracle Parallel Server and platform-specific documentation.
Listener load balancing is configured by defining multiple listeners for each database. Multiple listeners may exist either on the same platform as the database, or on different nodes as is the case with multi-threaded servers. To enable multiple listeners for multi-threaded servers, add the following parameter to your server's INIT.ORA configuration file:

MTS_MULTIPLE_LISTENERS=TRUE

For more information, refer to the Oracle8 Server Administrator's Guide.

/End Quote/

-Hope that helps
I am RU
They think they know but don't. At least I know I don't know - Socrates
Tony Chiu
Advisor

Re: Multiple Oracle listeners on ServiceGuard Cluster

Hi Ken,
I suspect that there may be some problems in one or two of the listener.ora files. If possible, try to startup one listener at any time and check whether the listener is listening on the ip address(es) & port as you configured/expected. And there should be no overlapping. Try using 'netstat -an' and check the output.

If everything seems ok one by one, I suspect that you may use the wrong ORACLE_HOME or lsnrctl to startup the listener.

Tony.
Ken Polton
Occasional Contributor

Re: Multiple Oracle listeners on ServiceGuard Cluster

Tony,
Thanks for your advice on using netstat to diagnose the problem. The listeners have always come up individually and the ORACLE_HOME defined at the top of the package start-up script, so it has to be the same as the ORACLE_HOME for the database startup.
Ken

========================================

Ramesh,
I haven't had the opportunity to test it, yet, but it would appear to support all packages listening for all databases and, thus, Guy's proposal to have one set of listener config files.

Do you have any idea why it is, as you put it, "simpler" to have unique ports - isn't the IP address, whether it's floating or not, sufficient to differentiate between the listeners??
Ken