Skip Headers

Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01

Home Book List Contents Index Master Index Feedback

---

Previous Next

View PDF

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

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

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 example 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 messages in the output and the following message, then RMAN cannot restore one of one of the specified files from your available backups:

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 encountered a problem restoring the specified file:

RMAN-03009: failure of restore command on c1 channel 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
Additional information: 3

If you do not see an error stack, then RMAN successfully 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 sets 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 keys:

   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 Files with RMAN". However, some of the most common scenarios for database restore and recovery are presented in full here:

• Whole Database Restore and Recovery: Scenario
• Restore and Recovery of Individual Tablespaces or Datafiles: Scenario

The procedures outlined 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 the 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 archived redo logs going back to the creation of that datafile. (With a complete set of redo logs, RMAN can re-create a datafile for which there is no backup, by creating an empty datafile and then re-applying all changes since the file was created as part of the recovery process.)

If automatic channels are configured, then RMAN allocates all channels configured for the available device types according to their parallelism settings. Otherwise, you must enclose your RESTORE and RECOVER command in a RUN block, and begin by manually allocating the appropriate DISK or sbt channels. Otherwise, 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 datafiles are damaged or lost. You must restore and recover the whole database.

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

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 manually 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 operation will skip read-only tablespaces. If a read-only tablespace is at the SCN where it became read-only after it is restored from backup, no redo will be applied to it when the rest of the database is recovered. You can force RMAN to restore any missing datafiles belonging to read-only tablespaces by using the CHECK READONLY option to the RESTORE command:

RMAN> RESTORE DATABASE CHECK READONLY;
RMAN> RECOVER DATABASE DELETE ARCHIVELOG;

If RMAN completes the recovery without error, you can open the database:

RMAN> ALTER DATABASE OPEN;

Restore and Recovery of Individual Tablespaces or Datafiles: Scenario

In this scenario, some but not all of the datafiles are 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 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:

1. Connect to the target database and the recovery catalog database (if applicable), and make sure the database is mounted or open.
2. Take the tablespaces affected offline using ALTER TABLESPACE ... OFFLINE IMMEDIATE if they are not already offline.
3. Run 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.)
4. 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 file 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 execute 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. The RESTORE CONTROLFILE command is used to restore the control file.

Except as noted, the procedures in this section assume that you are not 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 restore it to its default location (determined by rules described in the following section) or to one or more different locations of your choice, using the RESTORE CONTROLFILE... TO destination option.

Default Destination for Restore of the Control 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';
    RESTORE 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 control file from that backup to all of the control file locations listed in the CONTROL_FILES initialization parameter.

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 Reference

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 listed 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

If you have a recovery catalog, you do not have to set the DBID or use the control file autobackup to restore the control file. You can use the RESTORE CONTROLFILE command with no arguments, as shown here:

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.

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 CONTROLFILE from 'filename';

The control file copy found at the location specified by filename will be written to all locations listed in the CONTROL_FILES 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 parameter, 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 CONTROLFILE TO 'filename' [FROM AUTOBACKUP]:

RESTORE CONTROLFILE TO '/tmp/my_controlfile';

You can perform this operation 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.

Limitations When Using a Backup Control File

Note the following requirements after restoring the control file from backup:

• After you restore your database using a backup control file, you must run RECOVER DATABASE and perform an OPEN RESETLOGS on the database.
• After restoring a backup control file, entries for tempfiles in locally-managed 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 different scenarios (such as when using a recovery catalog, or restoring from a specific backup), see the discussion of RESTORE CONTROLFILE 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 your 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 restoring the SPFILE.

Note the following when restoring the SPFILE:

• If the instance is already started with the server parameter file, then you cannot overwrite the existing server parameter file.
• When the instance is started with a client-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 Solaris).
• Restoring the SPFILE is one situation in which a recovery catalog can simplify 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 initialization parameter file based on a backup of an SPFILE.

To restore the server parameter file:

1. 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 "Determining your DBID" for details on determining your DBID.

2. Shut down the instance and restart it without mounting. When the SPFILE is not available, RMAN starts the instance with a dummy parameter file. For example:

   RMAN> STARTUP FORCE NOMOUNT;
   
   

3. Restore the server parameter file. If restoring to the default location, then run:

   RMAN> RESTORE SPFILE FROM AUTOBACKUP; 
   
   

   If restoring to a nondefault location, then you could run commands as in the following example:

   RMAN> RESTORE SPFILE TO '/tmp/spfileTEMP.ora' FROM AUTOBACKUP;
   
   

4. Restart the instance with the restored file. If restarting with a server parameter file in a nondefault location, then create a new client-side initialization parameter file with the single 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 the autobackup, you must first set the DBID for your database, and then use the RESTORE SPFILE FROM AUTOBACKUP command. The 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 DEVICE 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 Reference

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 initialization 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 host 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 to its original location is described in "Restore and Recovery of Individual Tablespaces or Datafiles: Scenario". However, you may need to restore a datafile to a location other than its original location 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 location 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 referring to the datafiles by their new names.

As with restoring datafiles from backup to their original locations, you should take the affected tablespaces offline at the start of restoring datafiles from backup to a new location.

Then, create a RUN block to encompass your RESTORE and RECOVER commands. For each file to be moved to a new location, use the SET NEWNAME command to specify the 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 specified with SET NEWNAME, rather than its original location.

After the RESTORE command but before the RECOVER command in your RUN block, use a SWITCH command to update 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 issued 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 /olddisk and the new ones will be stored in /newdisk.

RUN
{
  SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
  SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE';
  # specify the new location for each datafile
  SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO 
                           '/newdisk/users01.dbf';
  SET NEWNAME 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/tools01.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 tablespaces online:

SQL 'ALTER TABLESPACE users ONLINE';
SQL 'ALTER TABLESPACE tools ONLINE';

Performing Media Recovery of a Database, Tablespace or Datafile

Media recovery reapplies 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;

You can also perform media recovery of individual tablespaces or datafiles, or skip certain tablespaces while recovering the rest of the database, as shown in the following examples:

RMAN> RECOVER DATABASE 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 backup any archived redo logs required during the recovery operation. If backups are stored on a media manager, channels must be configured or allocated for use in accessing backups stored there.

One very useful option in managing disk space associated with these restored files is the DELETE ARCHIVELOG option, which causes the deletion of restored 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 operation, 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 location, you can use this variation:

RUN {
    SET NEWNAME FOR DATAFILE 3 to NEW;
    RESTORE DATAFILE 3;
    SWITCH DATAFILE 3;
    RECOVER DATAFILE 3;
}

Oracle will store the restored 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 occured 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 details 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 Archived 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 restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and the LOG_ARCHIVE_DEST_1 parameters of the target database. These parameters are combined in a platform-specific fashion to form the name of the restored archived 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 parameter file.

To restore archived redo logs to a new location:

1. After connecting to the target database, make sure the database is mounted or open.
2. Perform the following operations within a RUN block, as shown in the following example script:
   1. Specify the new location for the restored archived redo logs using SET ARCHIVELOG DESTINATION.
   2. Restore the archived redo logs.

   This example restores all backup archived logs to a new location:

   RUN
   { 
     SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
     RESTORE ARCHIVELOG ALL;
     # restore and recover datafiles as needed
     .
     .
     .
   }
   

Restoring Archived Redo Logs to Multiple Locations

RUN 
{ 
  # Set a new location for logs 1 through 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 DESTINATION 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
  .
  .
  .
}

---

Previous Next

Copyright © 2003 Oracle Corporation All Rights Reserved.

Home Book List Contents Index Master Index Feedback