RE: Datafile recovery in datagaurd environment
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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Goulet, Dick
Sent: Friday, March 14, 2008 4:00 PM
To: jkstill_at_gmail.com; hrishy
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 / www.capgemini.com Fax: 508.229.2019 / Email: richard.goulet_at_capgemini.com 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.Received on Sat Mar 15 2008 - 13:54:35 CDT