RE: Timing for Cloning with Flashback Database vs other methods
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <bbel5@xxxxxxxxxxxx>, "'John Hallas'" <John.Hallas@xxxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 5 Dec 2008 16:12:07 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Bellows, Bambi (Comsys)
Sent: Friday, December 05, 2008 3:45 PM
To: John Hallas; oracle-l@xxxxxxxxxxxxx
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.
Other related posts:
