Re: Data Guard - Fast Start failover

  • From: kathryn axelrod <kat.axe@xxxxxxxxx>
  • To: Ram K <lambu999@xxxxxxxxx>
  • Date: Wed, 26 May 2010 23:29:33 -0700

Hi Ram,

Both actually. If you set up the observer with DGMGRL, you can only put it
in one location. However, if you set it up with OEM (one of the
few worthwhile features of OEM that doesn't cost extra), you get to set up a
main observer And a backup observer. Thus if the main observer goes down,
the backup takes over. Very nifty!

As for the tnsnames, this too is pretty spiffy. I think it's easiest to
explain with a setup example...

Create your tnsnames:
mydb =
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=off)(FAILOVER=ON)(ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1521))(ADDRESS=(PROTOCOL=tcp)(HOST=host2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=mydb.mydomain)))

Create a service:
exec dbms_service.create_service(service_name=>'mydb',network_name=>'mydb');

Create a trigger:

after startup on database

 declare

role varchar (30);

 begin

select database_role into role from v$database;

if role='PRIMARY' then

dbms_service.start_service('mydb');

else

dbms_service.stop_Service('mydb');

end if;

end;

The two issues with the failover connection are that the server changes and
the db name changes. Without any special setup, one would need to have
multiple tns strings or update their tns string after every failover.

The above steps take care of these issues as the tns string makes it such
that if mydb can't be found on host1, it looks for it on host2. (Thus it
doesn't matter which server is housing the primary.) And the service
name/trigger combo make it such that the primary db will always have the
name of mydb (and the standby never will). (Thus as long as you are
connecting to 'mydb', you Will be connecting to the primary.)


Hope this helps..
-k


Side note ->
We have yet to encounter any issues with DG (have DG on 9i, 10g, 11g and
FSFO on 10g & 11g) but I did just come across note 972207.1 which is
definitely worth reading before you pick your 11g version.


On Wed, May 26, 2010 at 6:47 PM, Ram K <lambu999@xxxxxxxxx> wrote:

>
> Thanks Kathryn. Did you install the observer in the DR site or at a third
> site?  Do the clients tnsnames need to be reconfigured in case of a failure
> when connecting to the new primary.
>
>
>
> On Wed, May 26, 2010 at 6:45 PM, kathryn axelrod <kat.axe@xxxxxxxxx>wrote:
>
>> You wouldn't even need FSFO if you have two hours of allowed downtime :)
>>
>> FSFO works ~phenomenally~ well. Right now we have it running on 11.1.0.7
>> with no issues...There is around 1minute of downtime if the primary crashes.
>>
>>
>> The only thing I'd throw out there is there are a few 11.1.0.7 DG specific
>> patches (see note 738538.1) that are recommended...Other than that, I
>> truly love DG/FSFO; it is amazing.
>>
>>
>> On Wed, May 26, 2010 at 3:41 PM, Ram K <lambu999@xxxxxxxxx> wrote:
>>
>>> Hello,
>>>
>>> We are planning on a new HA/DR solution for a new application that we are
>>> building. Most of our databases sit on SAN which is synchronosuly
>>> replicated via SRDF to a DR site. The users for this application want 2
>>> hr window within which the DB needs to available if it goes down. The vendor
>>> recommends clustering, but I am also looking at Dataguard with Fast start
>>> failover. The physical standby can be at the DR site. The DB will be on
>>> 11g.
>>>
>>> Has anyone used 11g DG with FSF? Any specific issues?  Does the DB come
>>> up quickly without any problem if the primary DB goes down?
>>>
>>> --
>>> Thanks,
>>> Ram.
>>>
>>
>>
>
>
> --
> Thanks,
> Ram.
>

Other related posts: