Re: Data Guard Rebuild
Date: Thu, 12 Jun 2014 12:10:00 -0400
Message-Id: <72666857-8ABD-4F2D-87E8-D0EFA6F2514C_at_gmail.com>
Thanks. I've thought about trying that but our daily incrementals can take a few hours and be a few hundred GB’s compressed. Often it seems like less work to just restore the archive logs and let transport ship them.
Kenny
On Jun 12, 2014 11:39 AM, "Andy Webster" <awframpton_at_gmail.com> wrote: I think you can take an incremental and apply it to the standby, to get it up-to-date and ready for accepting logs. I have never tried it though. You just need to know the SCN for when your standby was built.
thanks
Andy
On Thu, Jun 12, 2014 at 9:44 AM, Kenny Payton <k3nnyp_at_gmail.com> wrote: I create/rebuild standby databases from time to time and when they are large and going across our WAN they can take more than a day to complete, sometimes multiple days. These databases also have a high churn rate and generate a large amount of redo. Our normal backup processes delete the archived logs on the primary prior to completion of the standby and require restoring them on the primary after the managed recovery begins so that they can ship to the standby. We do not reserve enough space to keep multiple days of archived logs around.
I’m curious if anyone has another work around to this.
I have one that requires creating the shell of the database by restoring the control files and offline dropping all data files and configuring transport to ship logs to it. Once managed recover starts I just register the log files that have shipped so far and switch the transport service on the primary. This is a little clunky and fairly manual at this point and I would love an easier approach.
Thanks,
Kenny--
http://www.freelists.org/webpage/oracle-l
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Jun 12 2014 - 18:10:00 CEST