Re: brain dead

From: Tim Gorman <>
Date: Fri, 23 Jan 2009 16:07:52 -0700
Message-ID: <>


Thanks for the corrections and elaboration, Dan.

What else can be expected from a thread with the subject "brain dead", eh? :-)

Dan Norris wrote:
There's some clarification needed here regarding these parameters.

On Fri, Jan 23, 2009 at 10:29 AM, Tim Gorman <> wrote:
The purpose of the LOCAL_LISTENER parameter is to enable the database instance to contact the TNS Listener process on the local node. 

That is one reason, but the LOCAL_LISTENER parameter is also sent to the remote listeners when each instance registers with the remote listener. It is the contents of the local_listener parameter that is sent to the client when that client is redirected to a different node than the one to which it is connected (in the case of server-side load balancing). This is important--the contents of the local_listener parameter must be able to be used by the client. For example, if you have
then that means that the client has to be able to resolve the DNS name "racnode2-vip" correctly since that is the address to which the client will connect when redirected. It is possible, if you set the local_listener incorrectly, to make all server-side load balanced connections fail. In this example, if the server domain was and the client domain was, then the connections would likely fail because is not in DNS, only is registered.

This is a common oversight. local_listener is not only used to locate the listener on the same node where the instance is running. It is also used in RAC to redirect client requests to itself if that connection is redirected from another (remote) node. Therefore, I view the contents of local_listener to be much more important and critical than the contents of remote_listeners. remote_listeners is only used at instance registration time while local_listener is used routinely as new client connections are load balanced within the cluster.

I wrote a blog post about this a while ago at

Hope that helps and that I didn't hijack this thread too far away from the intended purpose.


Niall Litchfield wrote:
So I'm revisiting the MAA whitepapers with a view to getting my old notes on how to setup dataguard properly in line for RAC
I'm finding that the OracleNet config documentation is a bit light. Given a primary called CHICAGO and a standby called BOSTON, GLOBAL_DBNAME is CHIGACO.DOMAIN.COM they say that we should do the following
at the primary site 1
1) set db_unique_name to CHICAGO1
2) add a tnsnames entry for BOSTON
3) set service_names = CHICAGO1
at the standby site 1
1) set db_unique_name to BOSTON1
2) add a tnsnames entry for CHICAGO
3) set service_names = BOSTON1
I reckon that leaves the listener at the primary knowing about a service of chicago1 and at the standby a service of boston1 - similary for the second nodes. Wouldn't that mean the client tnsnames would need to be looking for a different service depending on which listener they contacted? That seems wrong.
they also talk about setting the LOCAL_LISTENER to LISTENERS_CHIGACO and LISTENERS_BOSTON but don't mention those tnsnames at all - I assume they are just load balanced tnsnames entries for all the listeners in the local cluster?
Am I missing something - before I try to fire up 4 VMs to test this out?
If anyone has a complete set of sqlnet config files they'd be willing to share off list (and sanitised for machines obviously) that would probably help.

Niall Litchfield
Oracle DBA
fighting a horrible, horrible cold and wanting to sleep.

-- Received on Fri Jan 23 2009 - 17:07:52 CST

Original text of this message