Re: Data Guard Rebuild

From: Jeremy Schneider <jeremy.schneider_at_ardentperf.com>
Date: Thu, 12 Jun 2014 11:08:10 -0500
Message-ID: <CA+fnDAbnKiDO=hDYZvaeHY9h_aQ6ZRxASD7-L56Ev9y9-7TiNQ_at_mail.gmail.com>

That's a pretty cool workaround actually. I don't have a good solution; I usually somehow find space to temporarily keep a lot of archivelogs online until I get the standby setup - and I watch it closely in the meantime. Or else I do archivelog restores on the primary after the shipping is setup and keep resolving gaps until it's caught up. I might try your idea.

-J

--
http://about.me/jeremy_schneider


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-l

Received on Thu Jun 12 2014 - 18:08:10 CEST