Re: Timing for Cloning with Flashback Database vs other methods

From: Jerry Cunningham <>
Date: Wed, 10 Dec 2008 16:07:42 -0500
Message-ID: <>


Wha-der they need it so danged fast fer, anyway? Why back in my day, we'd pony express the tapes and they'd be lucky to get their fancy schmancy duplicate database before the next full moon. Don' wanna spoil 'em...

  • A non-young non-whippersnapper

On Fri, Dec 5, 2008 at 12:42 PM, Bellows, Bambi (Comsys) <
> wrote:

> Hey there Listers!
> Cloning sure has more options nowadays than in the golden yesteryear,
> doesn't it? There's the simple file copy with the controlfile you backed up
> from trace… being the oldtimers' best friend; then there's the newfangled
> "duplicate database" , which has the oldtimers smackin their gums talkin
> about walkin to school in the snow, 5 miles each way, uphill, without
> boots. And, as if that weren't enough, there's this snazzy glittery clone
> achieved through flashback database, which has the oldtimers sittin in the
> dark waitin fer the young dbas to change the lightbulbs. And fine. But.
> Which one's fastest? We oldtimers could parallelize that copy and shove it
> to background faster than you could say gollygeewillikers… can RMAN do
> that? And what of this snazzydazzy flashback database for cloning? Can it
> start with a blank slate, or does it need a database to be created and stuff
> before it lets tear? And, really, seriously, what *are* the timings? One
> would assume that if the target database exists and is pretty much kept up
> to date, anything which just applies changes is going to be lickety-split
> faster, but what if it's not?
> I'm off to soak my teeth for awhile, but I appreciate any insights you
> whippersnappers might have… J
> Bambi.

Received on Wed Dec 10 2008 - 15:07:42 CST

Original text of this message