RE: Timing for Cloning with Flashback Database vs other methods

From: Bellows, Bambi \(Comsys\) <bbel5_at_allstate.com>
Date: Fri, 5 Dec 2008 15:01:32 -0600
Message-ID: <AD0CB572A820AB4E8E52ABD38950FD3605803EFD@a0001-xpo0150-s.hodc.ad.allstate.com>


While I enjoy a good pray as much as the next guy, I try to stay away from methodologies which depend on same. There was a project I worked on that put a cloud up for the network piece. When someone asked why there was a cloud there, the PM responded that "that's where miracles come from". Mmmm-hmmm... ;)  


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

Hi

2008/12/5 Bellows, Bambi (Comsys) <bbel5_at_allstate.com>

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.

What you could *possibly* do is the following:

  1. create a standby
  2. create a restore point on standby
  3. open standby read-write for testing
  4. pray you have saved enough flashback data to flashback your read-write standby to the point before you opened it read-write
  5. use rman incremental backups from primary (or standard managed recovery) to get the standby back up to date
  6. rinse & repeat.

jason.

--
http://jarneil.wordpress.com 

	
	 

	 

	

________________________________
From: John Hallas [mailto:John.Hallas_at_morrisonsplc.co.uk] Sent: Friday, December 05, 2008 2:25 PM To: Bellows, Bambi (Comsys); oracle-l_at_freelists.org Subject: RE: Timing for Cloning with Flashback Database vs other methods I wish I felt like a young whippersnapper. Niall did a presentation at UKPUG this week that made me feel very old and my younger colleague was nudging me constantly with a smirk on his face. What do you mean by cloning a database by flashback Bambi? I am not sure that option exists, even in 11g. You can flashback a database to a point in time using recover points but actually cloning a database is new to me. We are currently experimenting with doing an EM database clone (which uses RMAN behind the scenes anyway). Some success but if a few iffies with a Peoplesoft database still to resolve. Duplicate database is the way to go though. As Niall says, it can be speeded up and is pretty simple, especially if you can get it all scripted (and maybe use OMF files). John
________________________________
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bellows, Bambi (Comsys) Sent: 05 December 2008 17:43 To: oracle-l_at_freelists.org Subject: Timing for Cloning with Flashback Database vs other methods
______________________________________________________________________
Wm Morrison Supermarkets Plc is registered in England with number 358949. The registered office of the company is situated at Gain Lane, Bradford, West Yorkshire BD3 7DL. This email and any attachments are intended for the addressee(s) only and may be confidential. If you are not the intended recipient, please inform the sender by replying to the email that you have received in error and then destroy the email. If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments in any way. Wm Morrison Supermarkets PLC accepts no liability or responsibility for anything said in the email or its attachments and gives no warranty as to accuracy. It is the policy of Wm Morrison Supermarkets PLC not to enter into any contractual or other obligations by email. Although we have taken steps to ensure the email and its attachments are virus-free, we cannot guarantee this or accept any responsibility, and it is the responsibility of recipients to carry out their own virus checks.
______________________________________________________________________
-- http://www.freelists.org/webpage/oracle-l
Received on Fri Dec 05 2008 - 15:01:32 CST

Original text of this message