RE: Drawbacks to using real time apply?
Date: Mon, 2 Jun 2008 14:01:13 -0400
I've been using real time apply in a number of situations, works great, but before you do switch have a look at:
Note.386417.1 Gen Ext/Pub Redo Corruption Errors During Redo Transport Note.387174.1 Ext/Pub MAA - Data Guard Redo Transport and Network Best Practices
Just to be sure.
Dick Goulet / Capgemini
North America P&C / East Business Unit
Senior Oracle DBA / Hosting
Office: 508.573.1978 / Mobile: 508.742.5795 / www.capgemini.com Fax: 508.229.2019 / Email: richard.goulet_at_capgemini.com 45 Bartlett St. / Marlborough, MA 01752
Together: the Collaborative Business Experience
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Newman, Christopher Sent: Friday, May 23, 2008 9:41 AM
Subject: Drawbacks to using real time apply?
We have 3 standby databases running 10gR2, 2 physical and 1 logical in maximum performance mode. We also have a downstream CDC database using streams which registers its logs from one of the physical standbys. We are looking at switching to real time apply with our dataguard configuration. I don't see any problems with the streams because, in addition to shipping the redo real time, it appears that the archive logs always get shipped as well.
Has anyone encountered any problems with using real time apply? IE, LGWR ASYNC to their standbys? Redo getting backed up under heavy load? Network issues?
What happens if there is a long disconnect between the primary and a standby using real time apply? Will the standby revert to reading the archive log if the real time gap is large enough?
Also - Currently when I query ' select dest_name, status, recovery_mode from V$ARCHIVE_DEST_STATUS;' on our primary DB, the real time apply destination shows as valid, but the recovery_mode shows 'unknown', however the standby shows ' STANDBY_ARCHIVE_DEST VALID MANAGED REAL TIME APPLY'. In fact, it shows that for *all* archive locations on the standby. Is this normal behavior?
Thanks in advance - Chris
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
http://www.freelists.org/webpage/oracle-l Received on Mon Jun 02 2008 - 13:01:13 CDT