Re: Data Guard Rebuild
- From: Kenny Payton <k3nnyp@xxxxxxxxx>
- To: Jack van Zanen <jack@xxxxxxxxxxxx>
- Date: Fri, 13 Jun 2014 06:45:59 -0400
Exaggerating a bit on the frequency, it’s just something when the time arises
to create a new standby at our DR site the thought crosses my mind that others
might be doing something different that could make life easier. Adding
additional temporary archive log space on the primary could certainly help with
the problem but far less interesting.
On Jun 12, 2014, at 11:11 PM, Jack van Zanen <jack@xxxxxxxxxxxx> wrote:
> Hi
>
> Why not simply get more storage for keeping multiple days worth of archives
> and don't worry about it?
> Or am I missing the point.
>
> Why would you need to rebuild standby databases from time to time? Once in a
> blue moon sounds more than enough to me
>
> Jack
>
> Jack van Zanen
>
> -------------------------
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient. If you are not the intended recipient,
> please be aware that any disclosure, copying, distribution or use of this
> e-mail or any attachment is prohibited. If you have received this e-mail in
> error, please contact the sender and delete all copies.
> Thank you for your cooperation
>
>
> On Fri, Jun 13, 2014 at 12:44 AM, Kenny Payton <k3nnyp@xxxxxxxxx> 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--
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
