Re: RMAN Strategy

From: Tim Gorman <tim_at_sagelogix.com>
Date: Sat, 24 Apr 2004 08:37:38 -0600
Message-ID: <BCAFD7D2.13C3D%tim@sagelogix.com>

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_at_cox.net 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_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Sat Apr 24 2004 - 09:36:07 CDT