Re: brain dead

Niall,

The purpose of the LOCAL_LISTENER parameter is to enable the database instance to contact the TNS Listener process on the local node.  By default, the Oracle instance will try to contact the local TNS Listener process at TCP ports 1521 and 1526, so it is only required to be set when the TNS Listener port is something other than 1521/1526.  But, as with all assumptions, it is still a good idea to set it explicitly and banish any assumptions.  Anyway, the TNSNAMES entry for LOCAL_LISTENER need only specify the ADDRESS portion, and not the CONNECT_DATA portion, as follows...
local_xyz=(description=(address=((protocol=tcp)(host=xyz.domain.com)(port=1531))))
And that'll do it.  You can go ahead and specify CONNECT_DATA, but it'll be ignored.  If your local TNS Listener is listening on multiple ports and/or hostnames, then you might want to have multiple ADDRESS= clauses within an ADDRESS_LIST= clause, so that the database instance can find the listener at any one of those ports.  Again, not required, just a good idea...

The REMOTE_LISTENERS parameter is used for server-side load-balancing in RAC, so the TNS connect-string there is similar to LOCAL_LISTENER in that the CONNECT_DATA clause isn't necessary (if specified, it is unused), but here you'll want to specify the addresses of all the TNS Listeners on all the nodes in the RAC cluster. This way, the database instance can redirect an incoming connection to a less heavily-utilized instance.  I'm fairly certain that server-side load-balancing in RAC requires the Shared Servers sub-system, that it doesn't use "dedicated" servers.

As far as the SERVICE_NAMES parameter, I'm not sure why the document likes to identify each of the instances/nodes as separate services (i.e. CHICAGO1, CHICAGO2, BOSTON1, BOSTON2, etc).  Personally, I've always tended to match the SERVICE_NAMES to the DB_NAME, unless I'm trying to do something fancy like host multiple applications within the RAC cluster and designate different groups of instances to the various applications.  Of course, this isn't specific to RAC -- one can host multiple applications within a non-RAC database as well..  At any rate, I think the idea is to name the services for the applications, and use those service names across the entire cluster (i.e. CHICAGO1.SERVICE_NAMES = 'OE,AP', CHICAGO2.SERVICE_NAMES = 'AP,GL', CHICAGO3.SERVICE_NAMES = 'AP,OE', etc).  As I understand it, SERVICE_NAMES are a way of getting rid of the dependency on instance identification, and providing a naming method that can group or isolate instances without having to name the instances as such.  So, in a "MAA" Data Guard environment, we're going to want to designate the SERVICE_NAMES on the standby according to how we want to the standby to run when it becomes primary.  You can have a non-RAC standby for a RAC primary, so in which case (using the CHICAGO->BOSTON example of SERVICE_NAMES above), the non-RAC standby BOSTON could have SERVICE_NAMES = 'OE,AP,GL' so that all service names can run on the non-RAC database when it becomes primary.

Hope this helps...
Tim Gorman
consultant - Evergreen Database Technologies, Inc.
P.O. Box 630791, Highlands Ranch CO  80163-0791
website   = http://www.EvDBT.com/
email     = Tim@xxxxxxxxx
mobile    = +1-303-885-4526
fax       = +1-303-484-3608
Yahoo IM  = tim_evdbt


Niall Litchfield wrote:
So I'm revisiting the MAA whitepapers http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPrimaryRACPhysicalStandby.pdf 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
http://www.orawin.info
fighting a horrible, horrible cold and wanting to sleep.
-- http://www.freelists.org/webpage/oracle-l

Other related posts: