RE: Timing for Cloning with Flashback Database vs other methods

Bambi:  

If you're really only concerned about the performance boost for the 2nd through nth non-reinstantiate clones and if you can provision 2x the disk, then after you instantiate a standby (with RMAN and DataGuard, or roll your own - after all it is just recovery), you keep shipping and applying the logs. Then when you decide you want a fresh clone, you shut down the standby, copy it locally, and startup rename the copy. You'll have to use reset logs at that point - but that is starting up the renamed COPY of the STANDBY, not the STANDBY. Then you can restart and resume dataguarding or otherwise applying logs to the standby.  

Now if you have an extra machine and the storage is shareable, you can avoid the rename and use a different node. In that case you may be able to use split mirrors or a similar disk technology to do this really spanky fast. Even if you don't have an extra node you might be able to use split mirrors to associate a plex disassociated from one volume (the standby) to another volume (the clone that you start up with rename).  

All the usual extra overhead of needing to log otherwise nologging operations applies. This method has worked since 6.0.36.  

One thing though - you didn't say whether the clone was at a remote location. That is a big deal in deciding which technology to use.  

I'm not exactly sure what this has to do with the flashback database feature, but I suspect that feature got tangled into your conversation in regard to using it for resetting a "clone" to a known starting point for iteratively re-running test sets against a known starting point. That is actually very, very cool. If I recall correctly Cary and Tom Kyte each had that high up on their sweet new features of 11g lists. (And if they did they were right.)  

All the best,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bellows, Bambi (Comsys)
Sent: Friday, December 05, 2008 3:45 PM
To: John Hallas; oracle-l_at_freelists.org
Subject: RE: Timing for Cloning with Flashback Database vs other methods  

John --

Thanks for the email back. Duplicate database seemed to me to be the way to go. but, evidently, there's a nifty new feature called flashback database, which, when combined with RMAN and DataGuard, clones a database. The folks here seem pretty excited about the prospects. and if it just applies changes since the last clone, it would speed things up (for subsequent clones, of course), but I wanted to make sure that it would be as fast as it sounds, so I came to the List, home of all the experts one could ever wish for. ;)  

Thanks again for your response.

Bambi.

--
http://www.freelists.org/webpage/oracle-l