Re: 0% data loss setup ?
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 08 Mar 2004 09:30:16 -0700
Sriram,
> My understanding is that,
>
> 1. RMAN repository is in a different machine( To provide redundancy)
This is not correct. The RMAN repository really resides within the control
files of the database being backed up. The well-known "recovery catalog"
database is an optional feature that replicates data from the control files
and is capable of storing that data longer. The "recovery catalog" database
contains only a replicated copy of the RMAN repository -- the "main" RMAN
repository always resides in the control files. So, the "recovery catalog"
database is purely an option that should be considered only for what
advantages it brings, one of which is additional redundancy.
But think it through: if you are backing up control files to several places
constantly, how much more pure redundancy does a "recovery catalog" database
provide?
Frankly, control files are already a single-point-of-failure in Oracle, so
needing to safeguard them to protect the RMAN repository as well should not
come as a surprise. It is quite feasible, especially in small shops, to run
RMAN in NOCATALOG mode with no risk of data loss. You just have to be
obsessive about backing up (and practicing to restore) the controlfiles,
which is easy and should come naturally to any DBA.
> 2. We will have to wait till the redo is archived and then write the archived
> log to tape ASAP(using RMAN).
>
> In this case, if we have a half redo and the machine hosting the DB server
> crashes, how would we recover( Assuming the half redo is lost)?
Hence the admonition "get the stuff onto tape, as quick as you can".
Anything on disk is at risk. Only one copy of anything is a
single-point-of-failure, on disk or on tape. Having all copies of anything
in the same physical location is a single-point-of-failure, on disk or on
tape.
It would be fun to architect the "max protection" versions of Data Guard,
but has anyone run that in production yet? Especially in situations where
the LGWR is writing across a WAN for data-center failure (aka disaster
recovery) purposes? Just curious: I'm not aware of anyone who has gone
that "max protection" route into production, personally. Does anybody know
of a case?
And never forget, Data Guard does not perform recovery, only replication
(good or bad). So anything that gets written that you don't want written
is...well...written. In one of the middle levels of data protection, Data
Guard allows a lag or delay, but again, that is not nearly the same thing as
recovery...
I guess what I'm trying to say is: implementing clustering or replication
without a solid recovery mechanism in place first and foremost, and without
regularly testing it in the normal course of operations, is like putting
chrome trim on a junk car.
Get backups and recovery testing solid first, and they'll take care of 99%
of all data loss protection scenarios. And a lot cheaper and without
unadvertised side-effects on performance and complexity than any of those
big-name H/A features, to boot.
For that remaining 1%, where archived redo logs don't get backed up and full
media failure occurs, then consider one of the higher levels of Data Guard.
The 80/20 rule at work...
Hope this helps...
-Tim
on 3/8/04 5:28 AM, k.sriramkumar@xxxxxxxxxxxxxxxxxx at
k.sriramkumar@xxxxxxxxxxxxxxxxxx wrote:
> Hi Tim,
>
> I appreciate your Excellent coverage of RMAN. I have a doubt here. Pls help me
> to understand.
>
> <Quote>
> To ensure you don't lose a single committed transaction, get the stuff onto
> tape, as quick as you can
> </Unquote>
>
> My understanding is that,
>
> 1. RMAN repository is in a different machine( To provide redundancy)
> 2. We will have to wait till the redo is archived and then write the archived
> log to tape ASAP(using RMAN).
>
> In this case, if we have a half redo and the machine hosting the DB server
> crashes, how would we recover( Assuming the half redo is lost)?
>
> Best Regards
>
> Sriram Kumar
>
>
> -----Original Message-----
> From: Tim Gorman [mailto:tim@xxxxxxxxxxxxx]
> Sent: Monday, March 08, 2004 9:18 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: 0% data loss setup ?
>
>
>
> DISCLAIMER:
> This message contains privileged and confidential information and is intended
> only for the individual named.If you are not the intended recipient you should
> not disseminate,distribute,store,print, copy or deliver this message.Please
> notify the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system.E-mail transmission cannot be
> guaranteed to be secure or error-free as information could be
> intercepted,corrupted,lost,destroyed,arrive late or incomplete or contain
> viruses.The sender therefore does not accept liability for any errors or
> omissions in the contents of this message which arise as a result of e-mail
> transmission. If verification is required please request a hard-copy version.
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
