Re: Data Guard Rebuild
From: Mindaugas Navickas <mnavickas_at_yahoo.com>
Date: Thu, 12 Jun 2014 10:51:27 -0700 (PDT)
Message-ID: <1402595487.21926.YahooMailNeo_at_web164605.mail.gq1.yahoo.com>
You might also consider using Incrementally Updated Backup feature. In summary: * take database backup to copy specifying a TAG (you are doing this anyways already...may be without tag) * backup incremental level 1 tag 'TAG' for recover of copy with tag 'TAG' database plus archivelog; * recover copy of database with tag 'TAG'; After this gap of logs to be applied should remain small. Mike Navickas On Thursday, June 12, 2014 12:16:41 PM, Kenny Payton <k3nnyp_at_gmail.com> wrote: It works. I came up with a couple tricks for this. One was to automatically generate the register statements and execute them on the standby once the rebuild completes. Another was to share the same destination on the primary. That way when the rebuild is complete the destination is deferred, updated to new target and then restarted. That way you minimize duplicate shipping of logs. I still wish I could get the logs to ship while the rebuild is running. Kenny On Jun 12, 2014, at 12:08 PM, Jeremy Schneider <jeremy.schneider_at_ardentperf.com> wrote: 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 >> >> >> >
Date: Thu, 12 Jun 2014 10:51:27 -0700 (PDT)
Message-ID: <1402595487.21926.YahooMailNeo_at_web164605.mail.gq1.yahoo.com>
You might also consider using Incrementally Updated Backup feature. In summary: * take database backup to copy specifying a TAG (you are doing this anyways already...may be without tag) * backup incremental level 1 tag 'TAG' for recover of copy with tag 'TAG' database plus archivelog; * recover copy of database with tag 'TAG'; After this gap of logs to be applied should remain small. Mike Navickas On Thursday, June 12, 2014 12:16:41 PM, Kenny Payton <k3nnyp_at_gmail.com> wrote: It works. I came up with a couple tricks for this. One was to automatically generate the register statements and execute them on the standby once the rebuild completes. Another was to share the same destination on the primary. That way when the rebuild is complete the destination is deferred, updated to new target and then restarted. That way you minimize duplicate shipping of logs. I still wish I could get the logs to ship while the rebuild is running. Kenny On Jun 12, 2014, at 12:08 PM, Jeremy Schneider <jeremy.schneider_at_ardentperf.com> wrote: 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-lReceived on Thu Jun 12 2014 - 19:51:27 CEST