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@xxxxxxxx> 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. > > >