Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: 9i DataGuard, RAC primary - secondary offline for network maintenance

Re: 9i DataGuard, RAC primary - secondary offline for network maintenance

From: Tony Sequeira <>
Date: Wed, 06 Dec 2006 20:46:35 +0000
Message-ID: <>

Paul Drake wrote:
> On 12/5/06, Tony Sequeira <> wrote:
>> Hi all,
>> I have a 2 node 9i RAC primary (Win 2003), mandated by the
>> application.
>> Have a physical standby
>> All appears to be going well, teething problems over (touch wood).
>> The primary is running in maximum performance mode.
>> The secondary server is due to go down for about 24 hours for absolutely
>> vital electrical maintenance work.
>> I believe that this will be OK, and that the secondary will catch up
>> when brought online again.
>> Any think or know different? I'm trying to plan for any glitches now,
>> the primary database is a vital 24/7 system.
>> I am aware of Note:259804.1 - particularly the section 'Real
>> Application Clusters and Data Guard Redo Apply During a Network
>> Outage'.
>> Many thanks.
>> --
>> Tony Sequeira
> Tony,
> I would think about setting the standby log destination status to
> 'DEFER' during this time so that the primary isn't constantly
> attempting to reconnect to the standby.
> Paul

OSS came back saying essentially what you have said:

As the primary database is running in Maximum Performance mode , non-availability of the
Physical Standby database should have no effect on the functioning of the Primary Site.

As this is a planned outage , you might also want to set the log_archive_dest_state_x parameter
to defer for the Standby site. Also check if the log_archive_min_succeed_dest parameter can still be adhered to with the standby site being set to deferred.

Once the Physical Standby site is back up and running , archive log gaps would be automatically
resolved and the Physical Standby site would be back in sync with the Primary database.

Thanks all for the input.


Tony Sequeira

Received on Wed Dec 06 2006 - 14:46:35 CST

Original text of this message