SV: Logical standby transaction_consistency parameter to none

From: Birkir Bjornsson <birkir_at_teymi.is>
Date: Fri, 18 Feb 2005 15:02:16 +0000
Message-ID: <20050218150217067.00000016184@birkir-pc>

Thanks for your reply. I will look at the white paper you suggested. The st=
andby database in this case is used as a query database for a data warehous=
e. I will probably try setting it to none and If that doesn=B4t help me I g=

uess I will have to re-instantiate the Database.

Thanks again for your reply =

Birkir Bjornsson

-----Upphafleg bo=F0-----
Sendandi: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.o= rg] Fyrir h=F6nd Mark Bole
Sent: 18. febr=FAar 2005 14:17
Samrit: oracle-l_at_freelists.org
Efni: Re: Logical standby transaction_consistency parameter to none

Birkir Bjornsson wrote:
> =3D =

> =

> Im running a logical standby DB and I was wondering what=3D happends if I=
set
> transaction_consisstency parameter to none. The logical standby is behind=
by
> almost 8 days and I need to speed things up. All the tables have indexes =
so
> that’s not the problem I guess. But is it okei=3D to set the
> transaction_consisstency to none and try to get them in sync. Or wi=3D ll=
it
> mess up the standby database? =

> =

> Thanks Birkir =

Version?

There is a white paper on Metalink "9i SQL Apply Best Practices" which =

documents a moderate speed-up by setting transaction_consistency to =

NONE. Beware of trying to monitor the apply progress as user SYSTEM or =

SYS in this case, you won't see accurate information. Also, don't let =

users actually query anything while applying with this setting in =

effect, as results can be inconsistent.

Depending on your situation, it may be faster to simply re-instantiate =

your logical standby (if you can afford the brief outage of your primary =

to do so). If you are using this strictly for disaster recovery, a =

physical standby would be a better choice, and recovering 8 days worth =

of archived redo would probably go much faster too.

Mark Bole
http://www.bincomputing.com

--
http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Feb 18 2005 - 10:06:17 CST