Re: More on tns configurations in the context of Dataguard
- From: kathryn axelrod <kat.axe@xxxxxxxxx>
- To: sacrophyte@xxxxxxxxx
- Date: Fri, 2 Apr 2010 12:02:26 -0700
Ah...Sorry..I misunderstood. :)
My first question would be - out of curiosity - why would you need ten
service names?
And second question - how would you plan on keeping the primary service
names up to date? I'm thinking that you're going to have to hardcode the
multiple names into the trigger anyway (for the primary), so you might as
well write them in both the stop and start section...
For the standby, you could of course do the loop you mentioned, or perhaps
do an alter system set service_names. But if you have to list them anyway
for the primary...
On Fri, Apr 2, 2010 at 10:23 AM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote:
> Kathryn, what if you have 10 services and 2 databases (one primary, one
> standby)?
>
>
> On Fri, Apr 2, 2010 at 12:11, kathryn axelrod <kat.axe@xxxxxxxxx> wrote:
>
>> Hi Charles,
>>
>> You only need one service name in the trigger - that is the name of the
>> primary.
>> Thus if you have 10 databases (one primary, nine standbys), there would
>> be:
>> db1 - service_names=prim,db1
>> db2 - service_names=db2
>> db3 - service_names=db3
>> and so on.
>>
>> If you did a switchover from db1 to db2, it would look like:
>> db1 - service_names=db1
>> db2 - service_names=prim,db2
>> db3 - service_names=db3
>> ...
>>
>> In the above situation, you did the switchover and on db1, the trigger
>> said - am i primary? No. Stop the 'prim' service. And on db2 it said - am I
>> primary? Yes. Start the 'prim' service.* --Note it only stops/starts the
>> 'prim' service with this trigger. Thus if your question was literally 'what
>> if I have ten service names?' - then it will simply append those ten with
>> the additional service name. (Or stop the additional service and leave the
>> other ten running).*..
>>
>> The listeners have a static entry for db1, db2, db3, etc but a dynamic one
>> for 'prim'. Thus when db1 is no longer 'prim', its listener no longer
>> accepts connections for that name. Meanwhile, db2 becomes prim and its
>> listener starts accepting connections.
>>
>>
>> Hope this helps,
>> -k
>>
>>
>>
>>
>> On Fri, Apr 2, 2010 at 9:18 AM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote:
>>
>>> Good day, list,
>>>
>>> This references some past email exchanges:
>>>
>>> - Carel-Jan Engel: Data Guard (
>>> //www.freelists.org/post/oracle-l/Data-Guard,2)
>>> - Jeremy Schneider: TAF and node failover non RAC oracle 10.2 (
>>>
>>> //www.freelists.org/post/oracle-l/TAF-and-node-failover-non-RAC-oracle-102,18
>>> )
>>> - Me: Trying to wrap my head around TAF (
>>>
>>> //www.freelists.org/post/oracle-l/Trying-to-wrap-my-head-around-TAF,4
>>> )
>>>
>>>
>>>
>>> Also in reference to:
>>>
>>> - How to configure Client Failover after Data Guard Switchover or
>>> Failover (Doc ID 316740.1)
>>> - Failover Connections for Data Guard Error with ORA-1033 (Doc ID
>>> 461874.1)
>>>
>>>
>>> If I read this all correctly, the favored method to have a single tns
>>> connection string point to "both" (assuming two) databases in a DG
>>> configuration, you need:
>>>
>>> - the tns string with multiple addresses
>>> - properly defined service names
>>> - a trigger that turns the service off in the standby database
>>>
>>>
>>>
>>> So this brings up a question. Let's say, for example, you have 10
>>> services. That means you have to hardcode each of those services in the
>>> manage_OCI trigger (from Doc ID 461874.1)? And if you insert/update/delete
>>> any of those service names, you have to make appropriate changes to the
>>> trigger? Is that not kind of a pain?
>>>
>>> Here is where I am going with this. Does not Oracle provide a way to
>>> disable *all* services that are registered to the listener when the
>>> database is started as a standby? One could add a simple loop in the
>>> documented manage_OCI trigger to stop each entry in SERVICE_NAMES, but that
>>> seems like a hack. But maybe it is the only hack available to us at this
>>> point in time? The Oracle online documentation does not spell out any
>>> options for ALL services (too bad DBMS_SERVICE.STOP_SERVICE.SERVICE_NAME
>>> cannot
>>> be null *grin*). I realize you could do some magic with local_listener, but
>>> that seems to overly complicate matters, IMO.
>>>
>>>
>>>
>>> --
>>> Charles Schultz
>>>
>>
>>
>
>
> --
> Charles Schultz
>
Other related posts:
