Re: RMAN Restore and Recovery Scenario

From: Marc Bruinsma <marc.bruinsma_at_chello.nl>
Date: Sun, 26 Aug 2007 19:05:57 +0200
Message-ID: <0qiAi.287$9V2.130@amstwist00>

Michael42 wrote:

> Guys,
> 
> Thanks very much for the feedback.
> 
> -Michael

Hi Michael,

Like Frank said before me, there are quite a few scenarios that apply here, but that really depends on how exactly your environment was set up, i.e. are you using the FRA or not, is CONTROLFILE AUTOBACKUP configured, and if so, to the FRA or somewhere else, etc. etc.

But keep this in in mind: there is no such thing as 'RMAN files'. What you are (I think) referring to, is the backup information contained in the control files, and the backup sets you made with RMAN.

Having said that. there is one thing I don't quite understand, and that is when you say : "After the OS, Oracle 10g database product has been re-installed and the database rebuilt...".

What database??? After all, you don't have a database anymore, except in the backupsets, so what has been rebuilt?

What you do need to do, is to make sure that the directory structure for your database files is in place as it was before your system went up in smoke, because RMAN will need that to restore the database files, the controlfiles and rebuild the redo logs. That also applies to the admin dirctories (bdump/cdump/udump/etc.), because you will need those to start up the instance from your restored spfile.

Anyway, the order in which to proceed would be to (all steps are done in RMAN, except the first one):

• set the ORACLE_SID, then login to RMAN with : RMAN target /

RMAN> startup nomount (Note: this example is from one of my systems, so yours will look different)

startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter
file '/u01/app/oracle/product/10.2.0/db_1/dbs/inittest.ora'

starting Oracle instance without parameter file for retrival of spfile Oracle instance started

• restore the spfile. If you're using the FRA you can specify that from RMAN like :

RMAN> restore spfile from autobackup db_recovery_file_dest='<location of flash_recovery_area>' db_name='<db_name>';

Otherwise you will need the DBID like so:

RMAN> set dbid <dbid>
RMAN> run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '<location>/%F';
3> restore spfile from autobackup;
4> }

Then shutdown and startup, this time with the spfile.

• restore the control file. if you were using the FRA, it is something like:

RMAN> restore controlfile from autobackup;

This will look in the db_recovery_file_dest as defined in the spfile, and restore the controlfile. This controlfile will contain the backup information (your 'catalog'), and from there on it's pretty simple:

• restore database
• recover database
• alter database open resetlogs

If you are not using the FRA, you will need to specify where your control file backups are, something like :

RMAN> run {
2> set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '<location>/%F';
3> restore spfile from autobackup;
4> }

and the restore database etc....

And after that, IMMEDIATELY MAKE A NEW BACKUP!!!!!, because you just did a RESETLOGS. I'm sorry if this seems a long post, but the fact is that there are so many variables that there is no one scenario. The thing is to know where your backupsets are, and the directory structure of the database, the location of your FRA, the DBID's of your databases, and so on. So what I usually recommend is to make a list of the following of all the databases you are responsible for:

• the DBID
• the location of the FRA (if used)
• the location of the init.ora's you make from the spfiles
• the location of SPFILE/CTRLFILE autobackup
• backup location of the backupsets (if not in the FRA)

Also, make backups of your controlfiles to trace (should your controlfile backups be missing for whatever reason), so you can at least rebuild them, and make init.ora's from your spfiles, for the same reason.

Also, seriously consider using an RMAN catalog in a separate database. It takes very little in the way of resources in hardware and software, and it can really be helpful when the s**t hits the fan.

And as every DBA knows, the s**t usually hits the fan at 2:30AM, and you do not want to be hunting around for the required info at that time of night (believe me, I've been there :-( )

HTH,
Marc

p.s. do yourself a favor, and set up a basic database or two on a small box somewhere (one of them containing a recovery catalog) and practice (with and without a catalog) : break things, throw away controlfiles, spfiles, datafiles, and try to restore them, see what happens, figure out why and learn from it, because this will really help you (especially at 2:30AM!) Received on Sun Aug 26 2007 - 12:05:57 CDT