Re: dataguard protection mode...

From: Volker Hetzer <volker.hetzer_at_ieee.org>
Date: Wed, 27 Oct 2004 18:40:46 +0200
Message-ID: <cloj2f$ntp$1@nntp.fujitsu-siemens.com>

"Yong Huang" <yong321_at_gmail.com> schrieb im Newsbeitrag news:a8d66634.0410270805.7cc8c3d6_at_posting.google.com...

> "Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:<clnuv2$3jt$1_at_nntp.fujitsu-siemens.com>...
> > "Yong Huang" <yong321_at_yahoo.com> schrieb im Newsbeitrag news:b3cb12d6.0410261101.428f2f0f_at_posting.google.com...
> > > "Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:<cljm2i$spk$1_at_nntp.fujitsu-siemens.com>...

> > > > Hi!
> > > > I'm trying to switch from maximum performance to maximum availability mode
> > > > on 9.2.0.4.
> > > >
> > > > I did do standby redologs on the standby database:
> > > > GROUP# STATUS TYPE MEMBER
> > > > ---------- ------- ------- --------------------------------------------------------------------------------
> > > > 1 ONLINE /home/oracle/admin/NOBBY/DBFILES_LINKDIR/RedoLogs1/Redo1.rdo

> >  ...


> > > >          6         STANDBY /home/oracle/admin/NOBBY/DBFILES_LINKDIR/StbRedoLogs1/StbRedo1.rdo

> >  ...

> > > > And I did configure the Transport service (using dgmgrl):
> > > > log_archive_dest_3 string service="NOBBY_ORACLE3", LGWR NOAFFIRM delay=0 OPTIONAL max_failure=0 reopen=300 async=2048

> >  register

> > > >
> > > > Yet, when I "alter configuration set protection mode as maxavailability"
> > > > I get an ORA-16627.

> > >
> > > Hi, Volker,
> > >
> > > Change NOAFFIRM to AFFIRM and change async=2048 to SYNC in your
> > > log_archive_dest_3. Look at Table 5-2 in "Oracle Data Guard Concepts
> > > and Administration" in 9i documentation. The Data Guard Broker
> > > documentation doesn't seem to be complete.
> >
> > I guess that's it. I always thought SYNC, ASYNC and ARCH were the proper
> > modes, but after I opened a TAR support pointed out to me that I need to set
> > it to SYNC even for maxavailability.
> > 
> > Lots of Thanks nevertheless!
> > Volker
> 
> You imply that AFFIRM is not required.

Er, no. AFFIRM is required. But it is set automatically when you set the LogXprtMode property to SYNC.
In fact, you only have to set up the standby log and archive destinations (and start DMON) and then you can to do the rest with dgmgrl properties. Adding a site and setting the LogXprtMode *on that site* sets the log_archive_dest_n property of the primary site in the proper way. All that SERVICE=, LGWR AFFIRM and whatever else gets set by dgmgrl in that way.

> I don't have 9i data guard, but
> did a test on my 10.1.0.2.0 data guard. Surprisingly, both AFFIRM and
> SYNC can be omitted and I can still alter database set standby
> database to maximize availability. So it appears SYNC is required in
> 9i but optional in 10g.

Sounds great! I guess, dataguard doesn't set the stuff automatically in 9i because it can't decide which of the standby databases to upgrade and 10g is smart enough to so if there's only one standby location.

> 
> Just for a record. If I also omit LGWR, alter system set
> log_archive_dest_2 throws "ORA-16159: Cannot change protected standby
> destination attributes" when the database is in maximum availability
> mode. If I change it to max performance mode, startup mount and set to
> max availability mode, then alter database open throws ORA-3113.

Took me and the dataguard course guy a day to figure out the interplay between dataguard properties and database properties but in the end we found out that - dataguard (DMON) finds out if somebody has tampered with the initialisation   parameters and undoes the changes, giving you a lot of headaches until you figure   that out.
- it's better to go through dgmgrl for the standby stuff because then it's easier to   have consistent log_-properties.

Lots of Greetings!
Volker Received on Wed Oct 27 2004 - 11:40:46 CDT