RE: Datafile recovery in datagaurd environment

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <richard.goulet@xxxxxxxxxxxxx>, <jkstill@xxxxxxxxx>, "'hrishy'" <hrishys@xxxxxxxxxxx>
  • Date: Sat, 15 Mar 2008 14:54:35 -0400

. Hmm. I thought that ever since the MOSES papers everyone had sponged up
the notion of shipping the previous backup off site and copies up to date
(and possibly continuously offsite via network) of the archived redologs (if
not DG with current remote logging) so you only had to retrieve a tape to
your business continuation site (aka disaster site). If you have a local
logical problem that requires reloading a file, you probably want the
minimum time to recover, so you never surrender the most recent backup to
offsite unless you're writing duplicate tape sets to begin with.


I wonder if the MOSES papers are still available from Oracle. They might be
a bit antique, but the methods and standards are probably still logically
applicable. They were chock full of notions like the time to recover likely
being the most important metric of a backup and recovery system, but time to
back up not being so important as long as the overhead is tolerable during
the backup.







From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Goulet, Dick
Sent: Friday, March 14, 2008 4:00 PM
To: jkstill@xxxxxxxxx; hrishy
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Datafile recovery in datagaurd environment


Problem where no matter how slow the FTP is, is when you have to wait 4 days
for Iron Mountain to return the tape!!


Dick Goulet / Capgemini
North America P&C / East Business Unit
Senior Oracle DBA / Hosting
Office: 508.573.1978 / Mobile: 508.742.5795 /
Fax: 508.229.2019 /  Email: richard.goulet@xxxxxxxxxxxxx
45 Bartlett St. / Marlborough, MA 01752



This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.


Other related posts: