Re: RMAN Strategy
- From: Tim Gorman <tim@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 24 Apr 2004 08:37:38 -0600
Ryan,
By "RMAN user" I am assuming you mean a recovery catalog repository schema?
Think about the implications of this "deadly embrace" strategy, as that is
exactly what it is.
Consider the loss of database A. Where does that leave database B in terms
of recoverability? Of course it is unlikely that both A and B will have
need of recovery at the same time, but the road to hell is paved with such
assumptions.
There was an excellent paper at IOUG "Live 2004" by a lady named Bonnie
Bizzaro entitled "RMAN Recovery without Catalog or Controlfiles".
Essentially, they found themselves in a situation where the target database
and the recovery-catalog database both were wiped out because, while on
different servers, they were stored on the same SAN. Think that couldn't
happen to you? Makes me shudder just to think about it...
The recovery-catalog database had been backed up with exports, but for some
reason not in a while, so restoring it was useless. They could have tried
to restore a controlfile from the RMAN backups, but they would have to
search all of the whacko names that RMAN assigns to backupset pieces,
essentially restoring just about everything in search of a control file.
And, to top it off, without any controlfile to start with, you can't even
use the RMAN executable!
The upshot is that she had her logged output files from her RMAN jobs,
restored after the SAN crash, so from that she had some information about
the names of backupset pieces on tape. Also, she learned how to call the
procedures within DBMS_BACKUP_RESTORE from SQL*Plus, so she wrote little
PL/SQL scripts that emulated the RMAN executable.
So, once she was able to restore a decent controlfile, then she was able to
switch over to the RMAN executable in NOCATALOG mode and restore the rest of
the database. Of course, there were several to be restored, and some were
harder than others!
Her conclusions?
* Protect the recovery-catalog database with a standby database in
another data center altogether (chalk that up to "lessons learned
the hard way"!)
* Protect the recovery-catalog database with RMAN (nocatalog) and
exports (ditto!)
* Use the FORMAT command in the RMAN commands to provide a recognizable
name to backupset pieces on tape, so you can identify them and
retrieve them readily using just the media-management software
* Set CONTROL_FILE_RECORD_KEEP_TIME to a value much higher than its
default of 7 days (i.e. 14, 21, 30 days).
* Understand that RMAN is implemented entirely in PL/SQL and become
familiar with those packages, just in case...
Nothing about deadly-embraced recovery catalogs... :-)
I'd add a few more hard-earned tips:
* Always backup the controlfiles in a separate RUN command to a
recognizable name both on disk and onto tape -- you can never have
enough copies of the controlfile laying about
* Learn to build reports from both RMAN repositories, both the one
that always exists in the target database's controlfiles as well
as the optional one that might exist in the recovery catalog
database. The REPORT and LIST commands in the RMAN executable
are insufficient...
Thanks for the excellent paper, Bonnie!
-Tim
on 4/23/04 7:11 PM, Ryan at ryan.gaffuri@xxxxxxx wrote:
> This post isn't about how to use RMAN. Its about an appropriate strategy for
> using. From what I have seen alot of people like to use the following
> strategy:
> 1. Create an RMAN user in Database A on Server A
> 2. Create an RMAN user in Database B on Server B
> 3. RMAN on database A backs up up Database B
> 4. RMAN on Database B backs up Database A
>
> Does anyone take it further than this?
----------------------------------------------------------------
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:
