5
Perform ing Recovery

This chapter introduces the tools that RMAN make s available for recovering your database from backup. It includes the following topics:

• Database Restore and Recovery with RMAN: Overview
• Preparing and Planning Database Restore and Recovery
• Basic Database Restore and Recovery Scenarios
• Restoring Different Types of Lost Database Files with RMAN
< /ul>

Database Restore and Recovery with RMAN: Overview

The focus of this chapter is on how you use RMAN and backups created with RMAN to return your database to normal operation after the los s of one or more database files needed for its normal operation. The database files that RMAN backs up and can recover include the co ntrol file, server parameter file, datafiles and archived redo log files.

The chapter is or ganized as follows:

• "Preparing an d Planning Database Restore and Recovery" describes how to plan a restore-and-recovery operation, including how to determine which files need restore and recovery and what steps need to be taken during the recovery. It also descri bes how to preview the backups that RMAN will use during the restore operation, and how to verify that the backups to be used in the restore operation are valid.
• "Basic Database Resto re and Recovery Scenarios" presents some common database restore and recovery scenarios in their entirety. If one of these scenarios matches your situation, then you can follow the procedure outlined here. Even if the situation is not exactly the same, a review of the scenarios can help you create a plan for your own recovery process.
• "Restoring Different Types of Lost Database Files with RMAN" presents a number of recovery procedures in isolation, such as how to restore a control file, an SPFILE, individ ual datafiles and redo logs, along with requirements in the event that you restore a particular type of file, such as steps you must take if you are restoring from a backup control file. If your exact restore and recovery scenario is not one of the basic scenarios o utlined in the chapter, you can follow the processes outlined here to perform the individual tasks in your recovery plan.
< a name="1011138">

The two most important RMAN commands used in database recovery are:

• RESTORE, which retrieves files from RMAN backups based on the contents of the RMAN reposit ory
• RECOVER, which performs complete or point-in-time media recovery using ava ilable datafiles and redo logs.

Typically, you will set the state of the database app ropriately for the data recovery operation to be performed, allocate or configure channels required to communicate with the disk and media manager, and then run a series of RESTORE and RECOVER commands. RMAN retrieves all needed files from backup and performs media recovery on all restored datafiles, to return your database to the desired state.

Scope and Limitations of this Chapter

This chapter introduces the techniques which will cover the most common restore and recove ry scenarios. Anyone performing restore and recovery, even in complex scenarios not covered here, should be familiar with the techniq ues outlined in this chapter. Note, however, the following limitations on the scope of this discussion:

• Most of this chapter will focus on restore-and-recovery scenarios in which a media failure has damaged some or all of your database files, and your goal is to return your whole database to normal operation by restoring the d amaged files from backup and recover all database changes in the redo log. While some more advanced types of recovery, such as point- in-time recovery of the whole database or individual tablespaces to recover from user errors, are mentioned in passing, Oracle Database Backup and Recovery Advanced User's Guide< /em> provides more extensive information on these techniques.

  S ee Also: Oracle Database Backup and Recovery Advanced User's Guide for details on database point-in-time recovery (DBPITR) Oracle Database Backup and Recovery Adv anced User's Guide for details on tablespace point-in-time recovery (TSPITR)

• While there may be passing references to using RMAN with a recovery catalog, details on use of RMAN with a recovery catalog are covered in O racle Database Backup and Recovery Advanced User's Guide.
• The discuss ion in this chapter will be limited to Oracle databases running in a single-instance configuration. While RMAN can perform restore an d recovery of databases in Real Application Clusters and Data Guard configurations, such scenarios are beyond the scope of this manua l. After reviewing this chapter for the basics of backup and recovery, refer to Real Application Clusters Administration and Oracle Data Guard Concepts and Administration for more information about using RMAN in those contexts.

Restore and Recovery with Enterprise Manager

Enterprise Manager provides access to much of the database restore and recovery functionality provided by RMAN through a set of recovery wizards, that lead the DBA through a variety of recovery procedures based on an analysis of your database, your available ba ckups and your data recovery objectives.

Using RMAN through Enterprise Manager, you can per form the simpler restore and recovery scenarios outlined in this chapter, as well as much more sophisticated restore and recovery tec hniques such as point-in-time recovery and even use of the flashback features of the Oracle database, which allow for efficent repair of both media failure and user errors.

While the underlying functionality is the same, and the command-line client provides more flexibility, in many common situations, use of the Enterprise Manager interface to RMAN's rest ore and recovery features will be simpler than using the RMAN command line client directly.

See Oracle Database 2 Day DBA for more details on the restore and recovery features of Enterprise Manager.

While RMAN makes carrying out most database restore and recovery tasks m uch simpler, you still have to plan your database restore and recovery actions based on which database files have been lost and what your recovery goal is.

RMAN can make most of the important decisions about the restore proc ess for you, but you may want to preview and even override its decisions in some circumstances. For example, if you know a given back up is unavailable, due to a tape being stored offsite or a device being inaccessible, you can direct RMAN to not use that backup duri ng the restore process.

RMAN provides tools to let you preview which backups will be used i n a restore, and to validate the contents of the backups to ensure that they can be used in future restore operations.

Database Restore and Re covery Procedure: Outline

The basic procedure for performing restore and recovery with RMAN is as follows:

1. Determi ne which database files must be restored from backup, and which backups (which specific tapes, or specific backup sets or image copie s on disk) you will use for the restore operation. The files to be restored may include the control file, SPFILE, archived redo log f iles, and datafiles.
2. Place the database in the state appropriate for th e type of recovery that you are performing. For example, if you are recovering a single tablespace or datafile, then you can keep the database open and take the tablespace or datafile offline. Likewise, if you are restoring all datafiles, then you must shut down the database and then mount it before you can perform the restore.
3. Restore lost database files from backup with the RESTORE command. You may restore files to their original locations, or you may have to restore them to other locations if, for instace, a disk has failed. You may also have to update the SPFILE if you have chang ed the control file locations, or the control file if you have changed the locations of datafiles or redo logs.
4. Perform media recovery on restored datafiles, if any, with the RECOVER command.
5. Perform any final steps required to make the database available for us ers again. For example, restart the database if you are recovering from the loss of one copy of the control file, or bring offline ta blespaces online if you were only recovering a limited number of datafiles.

This outl ine is intended to encompass a wide range of different scenarios. Depending upon your situation, some of the steps described may not apply. For example, you do not need to perform media recovery if the only file restored from backup is the SPFILE. You will have to d evise your final recovery plan based on your particular situation.

Determining Which Database Files to Restore or Recover

It is generally obvious when the control file of your database must be restored, because the database shuts down immediately if any of the control file copies becomes inaccessible and the database cannot be started withou t a valid control file.

Loss of some but not all copies of your control file does not requi re recovery of the control file from backup. When one copy of the control file is lost, the database will automatically shut down. Yo u can either copy an intact copy of the control file over the damaged or missing control file, or update the parameter file so that < code>CONTROL_FILES does not refer to the damaged or missing control file. Once the CONTROL_FILES parameter refere nces only present, intact copies of the control file, you can restart your database.

Note t hat if you restore the control file from backup, you must perform media recovery of the whole database and then perform an OPEN RESETLOGS, even if no datafiles have to be restored.

The need to restore the SPFILE is also easy to determine-- if the instance cannot read the SPFILE during startup, then you should restore it from backup.

Identifying Datafi les Requiring Media Recovery

When and how to recover depends on the state of the database and the location of its datafiles. To determine which if any files require media recovery, use the following pr ocedure:

1. Start SQL*Plus and connect to the tar get database. For example, issue the following to connect to trgt:

   % sqlplus 'SY
   S/oracle@trgt AS SYSDBA'
   
   

2. Determine the s tatus of the database by executing the following SQL query:

   SELECT STATUS FROM V$INSTANCE;
   
   

   If the status is OPEN, then the database is open. How ever, some datafiles may require media recovery.

3. Check the recovery and error columns of the V$DATAFILE_HEADER view to determine the status of your datafiles. Run the following SQL statem ents to check the datafile headers:

   COL FILE# FORMAT 999
   COL STATUS FOR
   MAT A7
   COL ERROR FORMAT A10
   COL TABLESPACE_NAME FORMAT A10
   COL NAME
    FORMAT A30
   
   SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME 
   FROM V$DATAFILE_HEADER 
   WHERE RECOVER = 'YES' OR (RECOVER IS NULL AND ERROR IS NOT NULL);
   
   

If the ERROR column is not NULL or the RECOVER column is not NO, then check for a temporary hardware or operating system problem causing the error. If there is no such problem, you must restore the file or switch to a copy.

A NULL value in the RECOVER column indicates that some hardware error prevented RMAN from reading the file's header or verif ying its checksum.

If the ERROR column is NULL and the RECO VER column is YES, then the file can be recovered.

When you run the RMA N RECOVER command, incremental backups and archived redo logs are restored from backup as needed, and applied to the dat afile to recover it to the current SCN.

Note: Because V$DATAFILE_HEADER only r eads the header block of each datafile, it does not detect all problems that require the datafile to be restored. For example, you ca nnot tell whether a datafile contains corrupt data blocks using V$DATAFILE_HEADER.

• If you are planning to perform complete recovery rather th an point-in-time recovery, you can recover only those datafiles which require recovery, rather than the whole database. (Note that fo r point-in-time recovery, you must either restore and recover all datafiles or use the Oracle Flashback Database feature instead.) < p>

  You can query V$RECOVER_FILE to list datafiles requiring recovery by datafil e number with their status and error information.

  SELECT FILE#, ERROR, ONLINE, ONLINE_STAT
  US, CHANGE#, TIME 
         FROM V$RECOVER_FILE;
  
  

  You can also perform useful joins using the datafile number and the V$DATAFILE and V$TABLESPACE views, to get the datafile and tablespace names. Use the following SQL*Plus commands to format the output of the query:

  COL DF# FORMAT 999
  COL DF_NAME FORMAT A35
  COL TBSP_NAME FORMAT A7
  
  COL STATUS FORMAT A7
  COL ERROR FORMAT A10
  COL CHANGE# FORMAT 99999
  999
  SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, 
         d.STATUS, r.ER
  ROR, r.CHANGE#, r.TIME
  FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
  WHERE t.TS# =
  d.TS#
  AND d.FILE# = r.FILE#
  ;
  
  

  The ERROR column identifies the problem for each file requiring recovery.

  See Also: Oracle Database Reference for information about the V$ views

Determining your DBID

In situa tions requiring the recovery of your SPFILE or control file from autobackup, such as disaster recovery when you have lost all databas e files, you will need to determine your DBID. Your DBID should be recorded along with other basic information about your database, a s recommended in "Keeping Records of the Hardware and Software Configuration of the Server".

If you do not have a record of the DBID of your database, the re are two places you can easily find it.

• The DBID is used in forming the filename for the control file autobackup. Locate that file, and then refer to "Configuring th e Control File Autobackup Format" to see where the DBID appears in the filename.
• If you have any text files that preserve the output from an RMAN session, the DBID is displaye d by the RMAN client when it starts up and connects to your database. Typical output follows:

  % rman TARGET /
  Recovery Manager: Release 10.1.0.2.0 - Production
  
  Copyright (c) 1995, 2003, Oracle.  All rights reserved.
  
  connected to target database: R
  DBMS (DBID=774627068)
  
  RMAN>
  

Prev iewing Backups Used in Restore Operations: RESTORE PREVIEW

The < code>RESTORE command supports a PREVIEW option, which identifies the backups (backup sets or image copies, on dis k or sequential media like tapes) required to carry out a given restore operation, based on the information in the RMAN repository. U se RESTORE... PREVIEW when planning your restore and recovery operation, to ensure that all required backup s are available or to identify situations in which you may want to direct RMAN to use or avoid specific backups.

For example, RESTORE... PREVIEW can show you that RMAN will request a tape during the restore process which you know is stored offsite. You can then use the CHANGE... UNAVAILABLE command (desc ribed in "Marking a Backup AVAILABLE or UNAVAILABLE") to set the back up status to UNAVAILABLE. If you then run RESTORE... PREVIEW again, RMAN will show you the backups it would use to perform a restore operation without using the unavailable backup.

Using RESTORE... PREVIEW

RESTORE ... PREVIEW can be applied to any RESTORE operation to create a detailed report of every backup to be used in the requested RESTORE operation. Here are a few examples of RESTORE< /code> commands using the PREVIEW option:

RESTORE DATABASE PREVIEW;
RESTORE TABLESPACE users PREVIEW;
RESTORE DATAFILE 3 PREVIEW;
RESTORE ARCHIVE
LOG FROM LOGSEQ 200 PREVIEW;
RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW;
RESTORE AR
CHIVELOG FROM SCN 234546 PREVIEW;

RESTORE... P REVIEW output is in the same format as the output of the LIST command. See Oracle Database Recovery Manager Reference for details on i nterpreting the output of RESTORE... PREVIEW.

Using RESTORE... PREVIEW SUMMARY

If the detailed report produced by RESTORE... PREVIEW provides more information than is needed, use the RESTORE... PREVIEW SUMMARY option to suppress much of the detail abou t specific files used and affected by the restore process. Here are some examples of RESTORE used with the PREVIEW SUMMARY option:

RESTORE DATABASE PREVIEW SUMMARY;
RESTORE TABLESPACE users PREVIEW SUMMARY;
RESTORE DATAFILE 3 PREVIEW SUMMARY;
RESTORE A
RCHIVELOG FROM LOGSEQ 200 PREVIEW SUMMARY;
RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW SUMMARY;
RESTORE ARCHIVELOG FROM SCN 234546 PREVIEW SUMMARY;

< code>RESTORE... PREVIEW SUMMARY reports are in the same format as the output from the LIST SUM MARY command. See Oracl e Database Recovery Manager Reference for details on interpreting the output of RESTORE... PREVIEW SUMMAR Y.

Validating the Restore of Backups: RESTORE VALIDATE

The RESTORE ... VALIDATE and VALIDATE BACKUPSET commands test whether you can restore from your backups. You can test the restore of either the entire database or individual tablespaces, datafiles, or contr ol files. The contents of the backups are actually read to ensure that the objects to be restored can be restored from them. You have these options:

• RESTORE ... VA LIDATE tests whether RMAN can restore a specific object from a backup. RMAN chooses which backups to use.
• VALIDATE BACKUPSET tests the validity of a backup set that you specify.

See Also: Oracle Database Recovery Manager Reference for RESTORE syntax Oracle Database Recovery Manager Reference for VALIDATE syntax

Validating with RESTORE ... VALIDATE

To validate backups with RESTORE... VALIDATE, the database can be mounted or open. You do not have to take datafiles offline when validating them.

This ex ample illustrates validating the restore of the backup control file, SYSTEM tablespace, and all archived logs:

RESTORE CONTROLFILE VALIDATE;
RESTORE TABLESPACE SYSTEM VALIDATE;
RESTORE ARCHIVELOG ALL VALIDATE;

If you see error messa ges in the output and the following message, then RMAN cannot restore one of one of the specified files from your available backups:< /p>

RMAN-06026: some targets not found - aborting restore

If you see an error message stack and output similar to the following, for example, then RMAN encounte red a problem restoring the specified file:

RMAN-03009: failure of restore command on c1 ch
annel at 12-DEC-01 23:22:30
ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1"

ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Addition
al information: 3

If you do not see an error stack, then RMAN suc cessfully tested restore of the specified objects from the available backups.

Validating with VALIDATE BACKUPSET

The BACKUP VALIDATE command requires that you know the primary keys of the backup sets that you want to validate.

To specify which backup set s to validate:

1. If you do not need to validate the whole database, then find the backups that you want to validate by running LIST commands, noting primary ke ys:

   LIST BACKUP;
   
   

2. Validate the restore of the backup sets, referencing them by the primary keys. This example validates the restore of backup sets 1121 and 1122:

   VALIDATE BACKUPSET 1121,1122;
   
   

3. Check the output. If you see the validation complete message then RMAN successfully validated the restore of the specified backup set. For example:

   using channel ORA_DISK_1
   channel ORA_DISK_1: starting validation of archive log backupset
   channel ORA_DISK_1: restored backup piece 1
   piece handle=/oracle/dbs/0mdg9v8l_1_1 tag=TAG20020208T155604
    params=NULL
   channel ORA_DISK_1: validation complete
   

Basic Database Restore and Recovery Scenarios

You can plan a strategy for recovering from most data losses using the process outlined in "Preparing and Planning Database Restore and Recovery" and the task-specific procedures in "Restoring Different Types of Lost Database F iles with RMAN". However, some of the most common scenarios for database restore and recovery are presented in full here:

• Whole Dat abase Restore and Recovery: Scenario
• Restore a nd Recovery of Individual Tablespaces or Datafiles: Scenario

The procedures outli ned here will restore the whole database or individual tablespaces to their original locations.

To use the procedures in this section, the following requirements must be met:

• The current control file must be intact.
• You must have t he complete set of archived logs and incremental backups needed for media recovery of your available datafile backups.
• For any datafiles for which you have no backup, you must have a complete set of online and a rchived redo logs going back to the creation of that datafile. (With a complete set of redo logs, RMAN can re-create a datafile for w hich there is no backup, by creating an empty datafile and then re-applying all changes since the file was created as part of the rec overy process.)

If automatic channels are configured, then RMAN allocates all channel s configured for the available device types according to their parallelism settings. Otherwise, you must enclose your RESTORE and REC OVER command in a RUN block, and begin by manually allocating the appropriate DISK or sbt channels. Otherwi se, your RESTORE command will fail on attempting to retrieve backups from that device.

Whole Database Restore and Recovery: Scenario

In this scenario, you have a current control file and SPFILE but all datafile s are damaged or lost. You must restore and recover the whole database.

The database in thi s example has one read-only tablespace, history, which must be restored from backup but which does not need media recove ry.

To restore and recover the database when the current control file is available:

1. After connecting to the target database, make sure the database is mounted.

   RMAN> STARTUP MOUNT
   
   
   

2. Use the SHOW ALL command to see what channels are configured for access to backup devices. If automatic channels are not configured, then man ually allocate one or more channels.
3. Restore the database using the RESTORE command, and recover it using the RECOVER command.
4. Examine the output to see if recovery was successful. If so, open the database.

This example performs restore and recovery of the database, using automatic channels.

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 25MB;




The RECOVER DATABASE command as used here illustrates two useful options:


DELETE ARCHIVELOG causes RMAN to delete restored log
 files after they have been applied to the datafiles, to save disk space.
MAXSIZE 25MB limits space occupied by restored logs at any given moment to 25MB. This gives you more control over disk space
 usage by the restored logs. Note that if a single achived redo log file is larger than the specified MAXSIZE value, you
 will get an error. You will have to try your command again with a larger MAXSIZE value.
 
Read-only tablespaces may require special handling in a restore and recover operation. By default, the restore opera
tion will skip read-only tablespaces. If a read-only tablespace is at the SCN where it became read-only after it is restored from bac
kup, no redo will be applied to it when the rest of the database is recovered. You can force RMAN to restore any missing datafiles be
longing to read-only tablespaces by using the CHECK READONLY option to the RESTORE command:
RMAN> RESTORE DATABASE CHECK READONLY;
RMAN> RECOVER DATABASE DELETE ARCHIVELO
G;




If RMAN completes the recovery without error, you can open the
 database:
RMAN> ALTER DATABASE OPEN;



Restore and Recovery of Individual Tablespaces or Datafi
les: Scenario

 
In this scenario, some but not all of the datafiles ar
e damaged. You want to leave the database open so that the undamaged datafiles remain available.
 
Using the procedure described in "Determining Which Database Files to Restore or Recover" to identify datafiles needing recovery, you discover that the damaged datafiles are from the tablespaces <
code>users.
 
The following restore and recovery procedure can be used if the database
 is mounted or open.
 
To recover a tablespace to its current location:<
/strong>


Connect to the target database and th
e recovery catalog database (if applicable), and make sure the database is mounted or open.
<
a name="1037394">Take the tablespaces affected offline using ALTER TABLESPACE ... OF
FLINE IMMEDIATE if they are not already offline.
Ru
n SHOW ALL to see the current configuration, including configured default channels for the device where the
 backup is stored. If necessary, allocate one or more channels manually. (Note that if you manually allocate channels you must use a
RUN block around your command.)
Restore the tablespace or datafile with
 the RESTORE command, and recover it with the RECOVER command.
 
This example restores and recovers the users tablespace, letting RMAN choose the backup to use on disk or tape:
RMAN> SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
RMAN> RESTORE
 TABLESPACE users;
RMAN> RECOVER TABLESPACE users;




If RMAN reported no errors during the recovery, then bring the tablespace back online:
RMAN> SQL 'ALTER TABLESPACE users ONLINE';



Restoring Different Types of Lost Database Files with RMAN


 
This section discusses how to restore the different types of database fi
le backed up by RMAN. Once you have an overall plan for restoring the lost parts of your database, look here for details on how to ex
ecute the individual tasks in your plan.
 
Restoring the Control File from Backup

 
Loss or corruption of all copies of your control file requires restore of the control file from backup. T
he RESTORE CONTROLFILE command is used to restore the control file.

<
/table>

Except as noted, the procedures in this section assume that you are no
t using a recovery catalog. Restore and recovery procedures for the control file when using a recovery catalog are covered in Oracle Database Backup and Recovery Advanced User's Guide.
RMAN can restor
e it to its default location (determined by rules described in the following section) or to one or more different locations of your c
hoice, using the RESTORE CONTROLFILE... TO destination option.
Default Destination for Restore of the Contr
ol File
When restoring the control file, the default destination is
all of the locations defined in the CONTROL_FILES initialization parameter. If you do not set the CONTROL_FILES initialization parameter, the database uses the same rules to determine the destination for the restored control file as it uses
 when creating a control file if the CONTROL_FILES parameter is not set. These rules are described in Oracle Database SQL Reference
in the description of the CREATE CONTROLFILE statement.
 
Restore of the Control File from Control File Autobackup

 
If you are not using a recovery catalog, you must restore your control file from an
autobackup. If you want to restore the control file from autobackup, the database must be in a NOMOUNT state. You must first set the
DBID for your database, and then use the RESTORE CONTROLFILE FROM AUTOBACKUP command:
RMAN> SET DBID 320066378;
RMAN> RUN {
    SET CONTROLFILE AUTOBACKUP FORMAT
 
          FOR DEVICE TYPE DISK TO 'autobackup_format';
    REST
ORE CONTROLFILE FROM AUTOBACKUP;
    }




RMAN
 uses the autobackup format and DBID to determine where to hunt for the control file autobackup. If one is found, RMAN restores the c
ontrol file from that backup to all of the control file locations listed in the CONTROL_FILES initialization parameter.<
/p>
 
For information on how to determine the correct value for autobackup_format, see the description of CONFIGURE CONTROLFILE AUTOBACKUP FORMAT in the entry for CONFIGURE In Oracle Database Recovery Manager Ref
erence
 
See "Determining your DBID" for details on how to determine your DBID.
 
Restore of the Control File When a Flash Recovery Area is Used

 
The commands used for restoring your control file are the same, whether or not you are
using a flash recovery area. However, if you are using a flash recovery area, RMAN implicitly crosschecks backups and image copies li
sted in the control file, and catalogs any files in the flash recovery area not recorded in the restored control file. This improves
the usefulness of the restored control file in the restoration of the rest of your database.
 
Note that tape backups are not automatically crosschecked after the restore of a control file. If you are using tape backups, then
after restoring the control file and mounting the database you must crosscheck the backups on tape, as shown here:
RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;



Restore of the Control File When Using a Recovery Catalog
<
!--/TOC=h3-->
 
If you have a recovery catalog, you do not have to set the DBID or use the contro
l file autobackup to restore the control file. You can use the RESTORE CONTROLFILE command with no arguments, as shown h
ere:
RMAN> RESTORE CONTROLFILE;




The instance must be in NOMOUNT state when you perform this operation, and RMAN must be connected to the recovery catalog
. The restored control file will be written to all locations listed in the CONTROL_FILES initialization parameter.
<
a name="1040777"> 
Restore of the
 Control File From a Known Location

 
You can restore the control file
 from a known control file copy using this form of the command:
RMAN> RESTORE CONTROLFIL
E from 'filename';




The control file copy
found at the location specified by filename will be written to all locations listed in the CONTROL_FILES<
/code> initialization parameter.

 
Restore of the Control File to a New Location

 
One way to restore the control file to one or more new locations is to change the CONTROL_FILES initialization paramet
er, and then use the RESTORE CONTROLFILE command with no arguments to restore the control file to the default locations.
 For example, if you are restoring your control file after a disk failure made some but not all CONTROL_FILES locations
unusable, you can change CONTROL_FILES to replace references to the failed disk with pathnames pointing to another disk,
 and then run RESTORE CONTROLFILE with no arguments.
 
You can also restore the
control file to any location you choose other than the CONTROL_FILES locations, by using the form RESTORE CONTROLF
ILE TO 'filename' [FROM AUTOBACKUP]:
RESTORE CO
NTROLFILE TO '/tmp/my_controlfile';




You can perform this operatio
n with the database in NOMOUNT, MOUNT or OPEN states, because you are not overwriting any of the control files currently in use. Any
existing file named 'filename' is overwritten. After restoring the control file to a
new location, you can then update the CONTROL_FILES initialization parameter to include the new location.





Note:  
After restoring the control files of your database from ba
ckup, you must perform complete media recovery as described in "Performing Media Recovery of a Database,
Tablespace or Datafile", and then open your database with the RESETLOGS option. The only exceptio
n is the case described in "Restore of the Control File to a New Location", where you restore your control file to a location not listed in the CONTROL_FILES initialization parameter. In th
at case, you create a copy of your control file in the specified location without touching your running database.



  

 

 


 



See Also:  
Oracle Database Recovery Manager Referen
ce for RESTORE CONTROLFILE syntax.





  
Limitations When Using a Backup Control File

 
Note the following requirements after restoring the control file from bac
kup:

After you restore your database using a backup control fi
le, you must run RECOVER DATABASE and perform an OPEN RESETLOGS on the databa
se.
After restoring a backup control file, entries for tempfiles in locally-ma
naged temporary tablespaces are removed. Hence, you must add new tempfiles to these tablespaces after you OPEN RESETLOGS
. If you do not, then Oracle can display the error "ORA-25153: Temporary Tablespace is Empty" when attempting to sort.
 
For more details on restrictions on using RESTORE CONTROLFILE in differen
t scenarios (such as when using a recovery catalog, or restoring from a specific backup), see the discussion of RESTORE CONTROL
FILE in Oracle Database
 Recovery Manager Reference.
 
Restoring the Server Parameter File (SPFILE) from Backup

 
If you lose your server parameter file (SPFILE), RMAN can restore it to its default location or to a location of yo
ur choice.
 
Unlike the loss of the control file, the loss of your SPFILE does not cause your
 instance to immediately stop. Your instance may continue operating, although you will have to shut it down and restart it after rest
oring the SPFILE.
 
Note the following when restoring the SPFILE:

If the instance is already started with the server parameter file, then you cannot overwr
ite the existing server parameter file.
When the instance is started with a cl
ient-side initialization parameter file, RMAN restores the SPFILE to the default SPFILE location if the TO clause is not
 used. The default location is platform-specific (for example, ora_home/dbs/spfile.ora on Solari
s).
Restoring the SPFILE is one situation in which a recovery catalog can simp
lify your recovery procedure, because you can avoid the step of having to record and remember your DBID. This procedure assumes that
you are not using a recovery catalog.
 
RMAN can also create a client-side initializati
on parameter file based on a backup of an SPFILE.
 
To restore the serve
r parameter file:

If the database is
up at the time of the loss of the SPFILE, connect to the target database. For example, run: 
%
 rman TARGET /




If the database is not up when the SPFILE is lost
, and you are not using a recovery catalog, then you must set the DBID of the target database. See "Deter
mining your DBID" for details on determining your DBID.
Shut down the instance and restart it without mounting. When the SPFILE is not available, RMAN starts the in
stance with a dummy parameter file. For example: 
RMAN> STARTUP FORCE NOMOUNT;



Restore the server parameter file. If restoring to t
he default location, then run: 
RMAN> RESTORE SPFILE FROM AUTOBACKUP; 




If restoring to a nondefault location, then you could run commands as in the followi
ng example:
RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM AUTOBACKUP;



Restart the instance with the restored file. If rest
arting with a server parameter file in a nondefault location, then create a new client-side initialization parameter file with the si
ngle line SPFILE=new_location, where new_location is the path name of the
restored server parameter file. Then, restart the instance with the client-side initialization parameter file. 


For example, create a file /tmp/init.ora which contains the single line:
SPFILE=/tmp/spfileTEMP.ora




Then use this RMAN command, to
 restart the instance based on the restored SPFILE:
RMAN> STARTUP FORCE PFILE=/tmp/init
.ora; # startup with /tmp/spfileTEMP.ora




Restore of the SPFILE from the Control File Autobackup

 
If you have configured control file autobackups, the SPFILE is backed up with
the control file whenever an autobackup is taken.
 
If you want to restore the SPFILE from th
e autobackup, you must first set the DBID for your database, and then use the RESTORE SPFILE FROM AUTOBACKUP command. Th
e procedure is similar to restoring the control file from autobackup. You must first set the DBID for your database, and then use the
 RESTORE CONTROLFILE FROM AUTOBACKUP command:
RMAN> SET DBID 320066378;
RMAN> RUN {
    SET CONTROLFILE AUTOBACKUP FORMAT 
          FOR DE
VICE TYPE DISK TO 'autobackup_format';
    RESTORE SPFILE FROM AUTOBACKUP;
    }




RMAN uses the autobackup format and DBID to hunt
for control file autobackups, and if a control file autobackup is found, restores the SPFILE from that backup to its default location
.
 
For information on how to determine the correct value for autobackup_format, see the description of CONFIGURE CONTROLFILE AUTOBACKUP FORMAT in the entry for CONFIGURE In Oracle Database Recovery Manager R
eference

 
See "Determining your DBID" for details on how to determine your DBID.
 
Creating a Client-Side Initialization Parameter File (PFILE) with RMAN

 
You can also restore the server parameter file as a client-side initializatio
n parameter file with the TO PFILE 'filename' clause. The filename you specify should
 be on a filesystem accessible from the host where the RMAN client is running. This file need not be accessible directly from the hos
t running the instance. This command creates a PFILE called /tmp/initTEMP.ora on the system running the RMAN client:

RMAN> RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';




To restart the instance using the client-side PFILE, use the following command, again running RMAN on the
 same client machine:
RMAN> STARTUP FORCE PFILE='/tmp/initTEMP.ora';



Restoring and Recovering
Datafiles and Tablespaces to a New Location

 
Restoring a tablespace t
o its original location is described in "Restore and Recovery of Individual Tablespaces or Datafiles: Sce
nario". However, you may need to restore a datafile to a location other than its original locatio
n if, for example, the disk containing the original location of the datafiles has failed.
 
Restoring Datafiles from Backup to a New Location


 
The important step in restoring datafiles from backup to a new locatio
n is to update the control file to reflect the new locations of the datafiles. The following example shows the use of the RMAN 
SET NEWNAME command to specify the new names, and the SWITCH command to update the control file to start referrin
g to the datafiles by their new names.
 
As with restoring datafiles from backup to their ori
ginal locations, you should take the affected tablespaces offline at the start of restoring datafiles from backup to a new location.<
/p>
 
Then, create a RUN block to encompass your RESTORE and RECO
VER commands. For each file to be moved to a new location, use the SET NEWNAME command to specify th
e new location for that file.
 
Then, still within the RUN block, run the RESTORE TABLESPACE or RESTORE DATAFILE as normal. RMAN restores each datafile to the location specif
ied with SET NEWNAME, rather than its original location.
 
After the RESTO
RE command but before the RECOVER command in your RUN block, use a SWITCH command to up
date the control file with the new filenames of the datafiles. The SWITCH command is equivalent to the SQL statement ALTER DATABASE RENAME FILE. SWITCH DATAFILE ALL updates the control file to reflect the new names for all datafiles for which a SET NEWNAME has been iss
ued in the RUN block.

 
This example restores the datafiles in tablespaces users
 and tools to a new location, then performs recovery. Assume that the old datafiles were stored in directory /oldd
isk and the new ones will be stored in /newdisk.
RUN

{
  SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
  SQL 'ALTER TABLESPACE tools OFF
LINE IMMEDIATE';
  # specify the new location for each datafile
  SET NEWNAME FOR DATAFIL
E '/olddisk/users01.dbf' TO 
                           '/newdisk/users01.dbf';
  SET NEW
NAME FOR DATAFILE '/olddisk/tools01.dbf' TO 
                           '/newdisk/tools01.dbf';
  # to restore to an ASM disk group named dgroup, use: 
  # SET NEWNAME FOR DATAFILE '/olddisk/trgt/tool
s01.dbf'
  #     TO '+dgroup';
  RESTORE TABLESPACE users, tools;

 SWITCH DATAFILE ALL;   # update control file with new filenames
  RECOVER TABLESPACE users, tools;
}




If recovery is successful, then bring the tablespace
s online:
SQL 'ALTER TABLESPACE users ONLINE';
SQL 'ALTER TABLESPACE
tools ONLINE';






See Also:
  
Oracle Database Recovery Manager Reference for SWITCH syntax
 
Performing Media Re
covery of a Database, Tablespace or Datafile

 
Media recovery reapplie
s all changes from the archived and online redo logs and available incremental backups to datafiles restored from backup.
 
The simplest way to perform media reccovery is to use the RECOVER DATABASE command, with
no arguments:
RMAN> RECOVER DATABASE;



<
/a>
You can also perform media recovery of individual tablespaces or datafiles, or skip certain tablespaces while recov
ering the rest of the database, as shown in the following examples:
RMAN> RECOVER DATABA
SE SKIP TABLESPACE users;

RMAN> RECOVER TABLESPACE users, tools;

RMAN> RECOVER DATAFILE '/newdisk/users01.dbf','/newdisk/tools01.dbf';

RMAN> RECOVER DATAFILE 4;




RMAN will restore from bac
kup any archived redo logs required during the recovery operation. If backups are stored on a media manager, channels must be configu
red or allocated for use in accessing backups stored there.
 
One very useful option in manag
ing disk space associated with these restored files is the DELETE ARCHIVELOG option, which causes the deletion of restor
ed archived redo logs from disk once they are no longer needed for the RECOVER operation:
RMAN> RECOVER TABLESPACE users, tools DELETE ARCHIVELOG;




Note that when RMAN restores archived redo log files to the flash recovery area in order to perform a RECOVER ope
ration, the restored logs are automatically deleted after they are applied to the datafiles, even if you do not use the DELETE
ARCHIVELOG option.
 
See Oracle Database Recovery Manager Reference for more details on options for the RECOVER command.
 
Restore and Recover of Datafiles to a New Location

 
The procedure shown here is a convenient way to restore a datafile to a new location and perform media recovery on it.
RUN {
    SET NEWNAME FOR DATAFILE 3 to 'new_location';

RESTORE DATAFILE 3;
    SWITCH DATAFILE 3;
    RECOVER DATAFILE 3;

}




If you want to store a datafile to a new Oracle Managed Files l
ocation, you can use this variation:
RUN {
    SET NEWNAME FOR DATAFI
LE 3 to NEW;
    RESTORE DATAFILE 3;
    SWITCH DATAFILE 3;
    REC
OVER DATAFILE 3;
}




Oracle will store the re
stored file in an OMF location, generating a filename for it.
 
Point-in-Time Recovery of a Database or Tablespace

 
Point-in-time recovery lets you apply only those changes to your database or tablespace which occ
ured before a particular moment in time. Use point-in-time recovery to undo unwanted changes to your database, or to recover as many
changes as possible when you do not have a complete set of archived redo log files. See Oracle Database Backup and Recovery Advanced User's Guide for detail
s on database point-in-time recovery, and Oracle Database Backup and Recovery Advanced User's Guide for details on tablespace point-in-time recovery.
 
Restoring Archi
ved Redo Logs from Backup

 
RMAN will restore archived redo log files
from backup automatically as needed to perform recovery.
 
However, you can restore archived
redo logs manually if you wish, in order to save the time needed to restoroe these files later during the RECOVER command, or if you
want to store the restored archived redo log files in some new location.
 
By default, RMAN r
estores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and the LOG_ARCHIVE_DEST_1 p
arameters of the target database. These parameters are combined in a platform-specific fashion to form the name of the restored archi
ved log.
 

Restoring Archived Redo Logs to a New Location

 
You can override the
default location for restored archived redo logs with the SET ARCHIVELOG DESTINATION command.
This command manually stages archived logs to different locations while a database restore is occurring. During recovery, RMAN knows
where to find the newly restored archived logs; it does not require them to be in the location specified in the initialization parame
ter file.
 
To restore archived redo logs to a new location:

After connecting to the target database, make su
re the database is mounted or open.
Perform the following operations wi
thin a RUN block, as shown in the following example script: 

Specify the new location for the restored archived redo logs using SET ARCHIVELOG <
code>DESTINATION.
Restore the archived redo logs.
 
This example restores all backup archived logs to a new location:
RUN
{ 
  SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
  R
ESTORE ARCHIVELOG ALL;
  # restore and recover datafiles as needed
  .

  .
  .
}



Restoring Archived Redo Logs to Multiple Locations

 
You can specify restore destinations for archived logs mu
ltiple times in one RUN block, in order to distribute restored logs among several destinations. (You cannot, however specify multiple
 destinations simultaneously to produce multiple copies of the same log during the restore operation.) You can use this feature to ma
nage disk space used to contain the restored logs.
 
This example restores 300 archived redo
 logs from backup, distributing them across the directories /fs1/tmp, /fs2/tmp, and /fs3/tmp:<
/p>
RUN 
{ 
  # Set a new location for logs 1 thro
ugh 100.
  SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
  RESTORE ARCHIVELOG FROM SEQUENCE 1
 UNTIL SEQUENCE 100;
  # Set a new location for logs 101 through 200.
  SET ARCHIVELOG DE
STINATION TO '/fs2/temp';
  RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
  #
Set a new location for logs 201 through 300.
  SET ARCHIVELOG DESTINATION TO '/fs3/tmp';

  RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
  # restore and recover datafiles as needed
  .
  .
  .
}




When you issue a RECOVER command, RMAN finds the needed restored archived logs automatical
ly across the multiple destinations to which they were restored, and applies them to the datafiles.









Previous


Next


Copyright © 2003 Oracle Corporation

All Rights
Reserved.





Home


Book List


Contents



Index


Master Index


Feedback