|
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: -- //www.freelists.org/webpage/oracle-l |
