6.2 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 "RMAN RESTORE: Restoring Lost Database Files from Backup". However, some of the most common scenarios for database restore and recovery are presented in full here:

Restore and Recovery of a Whole Database: Scenario
Restore and Complete 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 commands 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.

6.2.1 Restore and Recovery of a Whole Database: 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:

After connecting to the target database, make sure the database is mounted.
```
RMAN> STARTUP MOUNT
```
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.
Restore the database using the RESTORE DATABASE command, and recover it using the RECOVER DATABASE command.
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 25M;

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 25M 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.

6.2.1.1 Recovery of Databases with Read-Only Tablespaces

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;

6.2.1.2 Re-Creation of Temporary Tablespaces in Whole Database Restore and Recovery

After restore and recovery of a whole database, when the database is opened, any missing temporary tablespaces recorded in the control file version of the RMAN repository are re-created with their previous creation size, AUTOEXTEND and MAXSIZE attributes.

Note:

Only temporary tablespaces that are missing are re-created. If a tempfile is still present at the location recorded in the RMAN repository but has an invalid header, then RMAN does not re-create the file.

If the tempfiles were originally created as Oracle-managed files, then they are re-created in the current DB_CREATE_FILE_DEST. Otherwise they are re-created at their previous locations.

If RMAN is unable to re-create the file due to an I/O error or some other cause, then the error is reported in the alert log and the database open operation continues.

Note:

When using a recovery catalog, if the control file has been restored from backup, the RMAN repository stored in the restored control file is updated with information about the temporary tablespaces recorded in the recovery catalog version of the RMAN repository. This ensures that the most recent configuration of temporary tablespaces is re-created.

6.2.2 Restore and Complete Recovery of Individual Tablespaces or Datafiles: Scenario

In this scenario, the database is open, and some but not all of the datafiles are damaged. You want to restore and recover the damaged tablespace, while leaving the database open so that the rest of the database remains available.

Assume that, 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.

This example restores and recovers the tablespace, using configured channels and letting RMAN choose the backups to use in restoring the tablespace and any needed incremental backups and logs from disk or tape.

Connect to the target database and the recovery catalog database (if applicable), and make sure the database is mounted or open. For example:
Take the tablespaces affected offline using ALTER TABLESPACE ... OFFLINE IMMEDIATE if they are not already offline.
```
RMAN> SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';
```
Restore the tablespace or datafile with the RESTORE command, and recover it with the RECOVER command. (Use configured channels, or if desired, use a RUN block and allocate channels to improve performance of the RESTORE and RECOVER commands.)
```
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';
```

At this point the process is complete.