Re: Data Guard Rebuild
Date: Fri, 13 Jun 2014 23:48:44 +1000
Message-ID: <CAHn_qA5SrKn_f=z5LWb-gGc2vSBxZnbJj_PKCVd94emmd+gCow_at_mail.gmail.com>
Would it be feasible to kick off your standby rebuild - let it complete. Then update the standby using an incremental backup (which could be compressed to send across the pipe)? I'm assuming that only a portion of your database would be changed between the standby refresh starting and completing. This may be far more efficient than running through media recovery on a large number of logs.
On 13 June 2014 22:42, Mark W. Farnham <mwf_at_rsiz.com> wrote:
> You’re welcome. Some of this stuff WAS more flexible when we had to “roll
> our own.”
>
>
>
> But RMAN and DATA GUARD prevent gaps in logic and provide the tools.
> Especially when ASM is in the mix this is a big bonus.
>
>
>
> àI think the enhancement request to be able to push archived redo logs to
> a remote listener service with or without an ASM target running has legs.
>
>
>
> Maybe you don’t have remote database even mounted or the disk farm
> currently powered on for the whole database. Cheaply providing a way to get
> a set of redo logs to a secure remote site seems worthwhile. Multiple
> destinations seems the most integrated solution, but the current
> requirements to send to a remote location seem like a big restriction to me.
>
>
>
> As for the shipping timing, that seems mostly like a non-technical
> contractual problem. Selecting a device that is easy transport and plug and
> unplug is the only technical part. I’d be shocked if you can’t find a colo
> that provides this sort of receipt and plug-in support for media as a minor
> charge or in the service contract. If you only need this infrequently and
> your WAN bandwidth is not needed constantly for other things, that still
> might be your best current price/performance solution.
>
>
>
> I believe though that database sizes will increase faster than WAN
> throughput. If I’m correct physical transport is likely in your future.
> Maybe you’ll use an Amazon drone.
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Jun 13 2014 - 15:48:44 CEST