Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

7 Advanced RMAN Recovery Techniques

This chapter describes how to perform restore and recovery using RMAN in a number of advanced scenarios.

This chapter contains the following topics:

Restore and Recovery of NOARCHIVELOG Databases

Restore of a database running in NOARCHIVELOG mode is very similar to restore of a database in ARCHIVELOG mode. The main differences are:

A limited form of restore and recovery is possible for NOARCHIVELOG databases if the backup strategy for the database includes incremental backups. The incremental backups (which, like the full backup of a NOARCHIVELOG database must be created when the database is shut down) can be applied to a full database backup to apply recent changes up to the time of the incremental backup.

Recovering a Database in NOARCHIVELOG Mode Using Incremental Backups

You can perform limited recovery of changes to a database running in NOARCHIVELOG mode by applying incremental backups. Note that the incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG mode, so you cannot make backups of the database when it is open.

Assume the following scenario:

  • You run database trgt in NOARCHIVELOG mode.

  • You use a recovery catalog.

  • You shut down the database consistently and make a level 0 backup of database trgt to tape on Sunday afternoon.

  • You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.

  • The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.

In this case, you must perform an incomplete media recovery until Friday, the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.

Because the online redo logs are lost, you must specify the NOREDO option in the RECOVER command.

You must also specify NOREDO if the online logs are available but the redo cannot be applied to the incrementals.

If you do not specify NOREDO, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them.

After connecting to trgt and the catalog database, recover the database with the following command:

STARTUP FORCE MOUNT;
RESTORE CONTROLFILE;  # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE;  # restore datafiles from consistent backup
RECOVER DATABASE NOREDO;  # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;

The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.

Note:

If the current online logs contain all changes since the last incremental , then you can run RECOVER DATABASE without specifying NOREDO. In such a case, the changes in the online logs are applied.

Restore and Recovery of the Database on a New Host

The procedure described in this section can be used to perform test restores, or to move a production database to a new host.

Note:

If your goal is to perform a test run of the disaster recovery procedures you would use following a real disaster, or to permanently move the target database to the new host, then use the procedure described in this section, which uses the RESTORE and RECOVER commands.

Note, however, that the DBID for the restored test database will be the same as the DBID for the original database. If, after the restore and recovery process is complete, you connect to the test database and the recovery catalog, the recovery catalog is updated with information about the test database that can interfere with RMAN's ability to restore and recover the source database.

If your goal is to create a new copy of your target database for ongoing use on a new host, then use the RMAN DUPLICATE command instead of this procedure. DUPLICATE assigns a new DBID to the duplicate database it creates, allowing it to be registered in the same recovery catalog as the original target database. See "Creating a Duplicate Database with RMAN: Overview" for details about duplicating a database.

Preparing for Restore of a Database to a New Host

To prepare for the restore of the database to a new host, take the following steps:

  • Record the DBID for your source database. If you do not know the DBID for your database, see Oracle Database Backup and Recovery Basics for details on ways to determine the DBID.

  • Make the source database initialization parameter file accessible on the new host. Copy the file from the old host to a new host using an operating system utility.

  • Make sure backups used for the restore are accessible on the restore host. For example, if the backups were made with a media manager, then make sure the tape device is connected to the new host.

Note:

If you perform a test restore only, then do not connect to the recovery catalog when restoring the datafiles. Otherwise, RMAN records information about the restored datafiles to the recovery catalog. This intereferes with future attempts to restore and recover the primary database. If you must use a recovery catalog because the control file is not large enough to contain the RMAN repository data on all of the backups that you need to restore, then export the catalog and import it into a different schema or database and use the copied recovery catalog for the test restore. Otherwise, the catalog considers the restored database as the current target database.

Testing the Restore of a Database to a New Host: Scenario

This scenario assumes the following:

  • Two networked machines, hosta and hostb, are running Linux

  • A target database named trgta is on hosta and uses a recovery catalog catdb

  • You want to test the restore and recovery of trgta on hostb, while keeping database trgta up and running on hosta

  • The directory structure of hostb is different from hosta, so that trgta is located in /net/hosta/dev3/oracle/dbs, but you want to restore the database to /net/hostb/oracle/oradata/test

  • Database trgta uses a server parameter file (not a client-side initialization parameter file)

  • The ORACLE_SID for the trgta database is trgta and will not change for the restored database

  • You have a record of the DBID for trgta

  • A media manager is accessible by both machines

  • You have recoverable backups on tape of all datafiles

  • You have backups of the archived logs required to recover the datafiles

  • You have control file and server parameter file autobackups on tape

Use the following steps to perform the restore process:

  1. Make backups of the target database available to hostb. To test disaster recovery, you need to have a recoverable backup of the target database. When preparing your disaster recovery strategy, ensure that the backups of the datafiles, control files, and server parameter file are restorable on hostb. Hence, you must configure the media management software so that hostb is a media manager client and can read the backup sets created on hosta. Consult the media management vendor for support on this issue.

    Configure the ORACLE_SID on hostb. This scenario assumes that you want to authenticate yourself through the operating system, which is much faster than configuring Oracle Net and creating a password file. However, you must be connected to hostb either locally or through a SQLNet alias.

    While connected to hostb with administrator privileges, edit the /etc/group file so that you are included: in the DBA group:

    dba:*:614:<your_user_name>
    

    Set the ORACLE_SID environment variable on hostb to the same value used on hosta:

    % setenv ORACLE_SID trgta
    

    Start RMAN and connect to the target instance without connecting to the recovery catalog.

    % rman TARGET / NOCATALOG
    

    Start the instance without mounting it. To start the instance, you first need to set the DBID. (If you do not know the DBID for your database, see Oracle Database Backup and Recovery Basics for details on how to determine the DBID.)

    Run SET DBID to set the DBID, then run STARTUP NOMOUNT:

    SET DBID 1340752057;
    STARTUP NOMOUNT
    

    RMAN will fail to find the server parameter file, which has not yet been restored, but will start the instance with a "dummy" file. Sample output follows:

    startup failed: ORA-01078: failure in processing system parameters
    LRM-00109: could not open parameter file '/net/hostb/oracle/dbs/inittrgta.ora'
    
    trying to start the Oracle instance without parameter files ...
    Oracle instance started
    

    Restore and edit the server parameter file.

    Because you enabled the control file autobackup feature when making your backups, the server parameter file is included in the backup sets.

    Allocate a channel to the media manager, then restore the server parameter file (SPFILE) as a client-side parameter file (PFILE).

    RUN
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
      RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP;
      SHUTDOWN ABORT;
    }
    

    Next, edit the restored PFILE. Change any location-specific parameters, for example, those ending in _DEST and _PATH, to reflect the new directory structure. For example, edit the following parameters:

    - IFILE
      - *_DUMP_DEST
      - LOG_ARCHIVE_DEST*
      - CONTROL_FILES
    

    Then restart the instance, using the edited PFILE:

    STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
    

    Restore the control file from an autobackup and then mount the database. RMAN restores the control file to whatever location you specified in the CONTROL_FILES initialization parameter. For example:

    RUN 
    {
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
      RESTORE CONTROLFILE FROM AUTOBACKUP;
      ALTER DATABASE MOUNT;
    }
    

    Query the database filenames recorded in the control file on the new host (hostb). Because the control file is from the trgta database, the recorded filenames use the original hosta filenames. You can query V$ views to obtain this information. Start a new SQL*Plus session and connect to the newly created instance on hostb:

    % sqlplus '/ AS SYSDBA'
    

    Run the following query in SQL*Plus:

    SQL> COLUMN NAME FORMAT a60
    SQL> SPOOL LOG 'db_filenames.out'
    SQL> SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
         UNION
         SELECT GROUP#,MEMBER FROM V$LOGFILE;
    SQL> SPOOL OFF
    SQL EXIT
    

    Write the RMAN recovery script. The script must include the following steps:

    • For each datafile on the destination host that is restored to a different path than it had on the source host, use a SET NEWNAME command to specify the new path on the destination host. (If the file systems on the destination system are set up to have the same paths as the source host, then do not use SET NEWNAME for those files restored to the same path as on the source host.)

  2. For each online redo log that is to be created at a different location than it had on the source host, use SQL ALTER DATABASE RENAME FILE commands to specify the pathname on the destination host. (If the file systems on the destination system are set up to have the same paths as the source host, then do not use ALTER DATABASE RENAME FILE for those files restored to the same path as on the source host.)

  3. Perform a SET UNTIL to limit media recovery to the end of the archived redo logs.

  4. Run SWITCH so that the control file recognizes the new path names as the official new names of the datafiles

  5. Restore and recover the database

    For example, consider the following RMAN script to perform these steps, which is contained in text file reco_test.rman:

    RUN
    {
      # allocate a channel to the tape device
      ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
    
      # rename the datafiles and online redo logs
      SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
      SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
      SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
      SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
      SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
      SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
      SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
      SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
      SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo01.log''
          TO ''?/oradata/test/redo01.log'' ";
      SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo02.log''
          TO ''?/oradata/test/redo02.log'' ";
    
      # Do a SET UNTIL to prevent recovery of the online logs
      SET UNTIL SCN 123456;
      # restore the database and switch the datafile names
      RESTORE DATABASE;
      SWITCH DATAFILE ALL;
    
      # recover the database
      RECOVER DATABASE;
    }
    EXIT
    

    Online logs and datafiles are relocated as specified,

    For example, connect and execute the script as shown here:

    % rman TARGET / NOCATALOG
    RMAN> @reco_test.rman
    

    RMAN will apply as many of the archived redo logs as it can and leave the database in a state in which is can be opened.

    Now perform an OPEN RESETLOGS at the restored database.

    Caution:

    When you re-open your database in the next step, do not connect to the recovery catalog. Otherwise, the new database incarnation created is registered automatically in the recovery catalog, and the filenames of the production database are replaced by the new filenames specified in the script.

    If this is a test restore, never connect RMAN to the test-restore database and the recovery catalog.

    From the RMAN prompt, open the database with the RESETLOGS option:

    RMAN> ALTER DATABASE OPEN RESETLOGS;
    

    If this was a test restore, and it was successful, then you can shut down the test database instance, and delete the test database with all of its files. Use the DROP DATABASE command to delete all files associated with the database automatically.

    Note:

    If you used an ASM disk group, then DROP DATABASE is the only way to safely remove the files of the test database. If you restored to non-ASM storage then you can also use operating system commands to remove the database.
    RMAN> SHUTDOWN ABORT
    RMAN> EXIT
    

    Remove all test files. You can do this with an operating system utility or in RMAN. For example, in Unix you could perform the procedure this way:

    % rm $ORACLE_HOME/oradata/test/*
    

    You can also use RMAN for a procedure that works on all platforms. For example:

    RMAN> STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
    RMAN> DROP DATABASE;
    

    Because you did not perform the restore and recovery when connected to the recovery catalog, the recovery catalog contains no records for any of the restored files or the procedures performed during the test. Likewise, the control file of the trgta database is completely unaffected by the test.

Performing Recovery with a Backup Control File

If all copies of the current control file are lost or damaged, then you must restore and mount a backup control file before you can perform recovery. When using a backup control file, and using a recovery catalog, the process is identical to recovery with a current control file, as the RMAN repository information missing from the backup control file is available from the recovery catalog. There are special considerations when using a backup controlfile and not using a recovery catalog.

The following notes and restrictions apply regardless of whether you use a recovery catalog:

Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario

This section assumes that you have RMAN backups of the control file, but do not use a recovery catalog.

Assuming that you enabled the control file autobackup feature for the target database, you can restore an autobackup of the control file. Because the autobackup uses a default format, RMAN can restore it even though it does not have a repository available that lists the available backups. You can restore the autobackup to the default or a new location. RMAN replicates the control file to all CONTROL_FILES locations automatically.

Note:

If you know the backup piece name (for example, from the media manager or because the piece is on disk), then you can specify the piece name using the RESTORE CONTROLFILE FROM 'filename' command. The server records the location of every autobackup in the alert log.

Because you are not connected to a recovery catalog, the RMAN repository contains only information about available backups at the time of the control file backup. If you know the location of other usable backup sets or image copies, add them to the control file RMAN repository with the CATALOG command.

Because the repository is not available when you restore the control file, you must use the SET DBID command to identify the target database. The DBID is used to determine the location of control file autobackups. Use SET DBID command only in the following special circumstances:

  • You are not connected to a recovery catalog and want to restore the control file or server parameter file.

  • You are connected to a recovery catalog and want to restore the control file, but the database name is not unique in the recovery catalog.

  • The server parameter file is lost and you want to restore it.

To recover the database with an autobackup of the control file without a recovery catalog:

Start RMAN and connect to the target database. For example, run:

CONNECT TARGET /

Start the target instance without mounting the database. For example:

STARTUP NOMOUNT;

Set the database identifier for the target database with SET DBID. RMAN displays the DBID whenever you connect to the target. You can also obtain it by inspecting saved RMAN log files, querying the catalog, or looking at the filenames of control file autobackup. (refer to "Restoring Control File When Databases in the Catalog Have the Same Name: Example"). For example, run:

SET DBID 676549873;

Restore the autobackup control file, then perform recovery. Do the following:

Optionally, specify the most recent backup time stamp that RMAN can use when searching for a control file autobackup to restore.

If you know that a different control file autobackup format was in effect when the control file autobackup was created, then specify a nondefault format for the restore of the control file.

If the channel that created the control file autobackup was device type sbt, then you must allocate one or more sbt channels. Because no repository is available, you cannot use preconfigured channels.

Restore the autobackup of the control file, optionally setting the maximum number of days backward that RMAN can search (up to 366) and the initial sequence number that it should use in its search for the first day.

If you know that your control file contained information about configured channels that will be useful to you in the rest of the restore process, you can exit the RMAN client at this point, to clear manually allocated channels from step "c". If you then restart the RMAN client and mount the database those configured channels become available for your use in the rest of the restore and recovery process.

If you do not care about using configured channels from your control file, then you can simply mount the database at this point.

If the online logs are usable, then perform a complete restore and recovery as described in Oracle Database Backup and Recovery Basics.

Otherwise, restore and perform incomplete recovery of the database, as described in Oracle Database Backup and Recovery Basics Use an UNTIL clause to specify a target time , SCN or log sequence number for the recovery prior to the first SCN of the online redo logs.

In this example, the online redo logs have been lost, and the most recent archived log sequence number is 13243. This example shows how to restore the control file autobackup, then performs recovery of the database to log sequence 13243.

RUN 
{
  # Optionally, set upper limit for eligible time stamps of control file 
  # backups
  # SET UNTIL TIME '09/10/2000 13:45:00';
  # Specify a nondefault autobackup format only if required
  # SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK 
  #   TO '?/oradata/%F.bck';
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...'; # allocate manually
  RESTORE CONTROLFILE FROM AUTOBACKUP
    MAXSEQ 100           # start at sequence 100 and count down
    MAXDAYS 180;         # start at UNTIL TIME and search back 6 months
  ALTER DATABASE MOUNT DATABASE;
}
# uses automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13243;
RECOVER DATABASE UNTIL SEQUENCE 13243; # recovers to latest archived log

If recovery was successful, then open the database and reset the online logs:

ALTER DATABASE OPEN RESETLOGS;

Performing Disaster Recovery

Disaster recovery includes the restore of and recovery of the target database after the loss of the entire target database, the recovery catalog database, all current control files, all online redo log files, and all parameter files.

To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.

The basic procedure for disaster recovery begins with restoring an autobackup of the server parameter file, as described in Oracle Database Backup and Recovery Basics.

Once you have an SPFILE, you can start the target database instance, restore the control file from autobackup and mount it.

With the control file mounted, then follow the instructions found in "Performing Recovery with a Backup Control File" to restore and recover your datafiles.

Note:

If you are restoring to a new host, you should review the considerations described in "Restore and Recovery of the Database on a New Host".

The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:

In this scenario, perform the following steps:

If possible, restore all relevant network files such as tnsnames.ora and listener.ora by means of operating system utilities.

Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect using operating system authentication.

Specify the DBID for the target database with the SET DBID command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario".

Run the STARTUP NOMOUNT command. RMAN attempts to start the instance with a dummy server parameter file.

Allocate a channel to the media manager and then run the RESTORE SPFILE FROM AUTOBACKUP command.

Run STARTUP FORCE NOMOUNT mode so that the instance is restarted with the restored server parameter file.

Allocate a channel to the media manager and then restore a control file autobackup (refer to"Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario").

Mount the restored control file.

Catalog any backups not recorded in the repository with the CATALOG command (refer to"Removing DELETED Records From the Recovery Catalog After Upgrade").

Restore the datafiles to their original locations. If volume names have changed, then run SET NEWNAME commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to"Performing Disaster Recovery").

Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.

Open the database in RESETLOGS mode. Only complete this last step if you are certain that no other archived logs can be applied.

# Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt

# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT;  # rman starts instance with dummy parameter file
RUN
{
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;  

RMAN> RUN
{
  # Manually allocate a channel to the media manager
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  # Restore autobackup of the control file. This example assumes that you have 
  # accepted the default format for the autobackup name.
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  #  The set until command is used in case the database
  #  structure has changed in the most recent backups, and you wish to
  #  recover to that point-in-time. In this way RMAN restores the database
  #  to the same structure that the database had at the specified time.
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 1124 THREAD 1;
  RESTORE DATABASE;
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery completes

The following example of the RUN command shows the same scenario except with new filenames for the restored datafiles:

RMAN> RUN
{
  #  If you need to restore the files to new locations, tell Recovery Manager
  #  to do this using SET NEWNAME commands:
  SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
  SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
  SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 124 THREAD 1;
  RESTORE DATABASE;
  SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
  RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;

Performing Block Media Recovery with RMAN

The BLOCKRECOVER command can restore and recover individual datablocks within a datafile. This procedure is useful when a trace file or standard output reveals that a small number of blocks within a datafile are corrupt.

Block media recovery is not useful in cases where the extent of data loss or corruption is not known; in this case, use datafile recovery instead.

See Also:

Block Media Recovery Using All Available Backups

In this scenario, you identify the blocks that require recovery and then use any available backup to perform the restore and recovery of these blocks.

To recover datablocks by using all available backups:

Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the alert.log, trace files, or a media management interface. For example, you may see the following in a trace file:

ORA-01578: ORACLE data block corrupted (file # 8, block # 13)
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

Assuming that you have preallocated automatic channels, run the BLOCKRECOVER command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks as in the following example:

RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19;

Block Media Recovery Using Specific Backups

In this scenario, you identify the blocks that require recovery, and then use only selected backups to perform the restore and recovery of these blocks.

To recover datablocks while limiting the type of backup:

Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the alert.log, trace files, or a media management interface. For example, you may see the following in a trace file:

ORA-01578: ORACLE data block corrupted (file # 8, block # 13)
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

Assuming that you have preallocated automatic channels, execute the BLOCKRECOVER command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks and limiting the backup candidates by means of the available options. For example, you can specify what type of backup should be used to restore the blocks:

# restore from backupset
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
# restore from datafile image copy
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 
      FROM DATAFILECOPY;

You can indicate the backup by specifying a tag:

# restore from backupset with tag "mondayam"
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 199 
      FROM TAG = mondayam;

You can limit the backup candidates to those made before a certain point:

# restore using backups made before one week ago
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 
  RESTORE UNTIL 'SYSDATE-7';
# restore using backups made before SCN 100
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 
  RESTORE UNTIL SCN 100;
# restore using backups made before log sequence 7024
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 
  RESTORE UNTIL SEQUENCE 7024;

Note that if you limit the restore of datablocks with the UNTIL clause, then RMAN must perform more recovery on the blocks, and the recovery phase must scan all logs for changes to the specified blocks.

Block Media Recovery of Blocks Listed in V$DATABASE_BLOCK_CORRUPTION

The V$DATABASE_BLOCK_CORRUPTION view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP or BACKUP VALIDATE command was run. After a corrupt block is repaired, the row identifying this block is deleted from the view.

You can check for logical corruption in the database by running the BACKUP (with or without VALIDATE option) with the CHECK LOGICAL command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.

In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION LIST keyword.

To recover datablocks while limiting the type of backup:

Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist in the most recent backups of the datafiles:

SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;

Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION by running the BLOCKRECOVER CORRUPTION LIST command. For example, this command restores blocks from backups created more than 10 days ago:

BLOCKRECOVER CORRUPTION LIST 
  RESTORE UNTIL TIME 'SYSDATE-10';

See Oracle Database Backup and Recovery Reference for more details on block media recovery in RMAN.

RMAN Restore and Recovery Examples

The following sections illustrate the use of RMAN restore and recovery techniques in advanced scenarios.

Restoring Datafile Copies to a New Host: Example

To move the database to a new host by means of datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.

After connecting to the target database and recovery catalog, run a LIST command to see a listing of datafile copies and their associated primary keys, as in the following example:

LIST COPY;

Copy the datafile copies to the new host with an operating system utility. For example, in UNIX:

% cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgt

Start RMAN and then uncatalog the datafile copies on the old host. For example, enter:

CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;

Catalog the datafile copies, using their new filenames or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH). For example, run:

CATALOG START WITH '?/oradata/trgt/';

Or this example specifies files individually:

CATALOG DATAFILECOPY
  '?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf', 
  '?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
  '?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf', 
  '?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';

Perform the restore and recovery operation described in "Performing Disaster Recovery".

Restoring Control File When Databases in the Catalog Have the Same Name: Example

When using a recovery catalog and attempting to restore a lost control file, you encounter an error if there are other databases are registered in the recovery catalog with the same name as your target database.

To resolve this error, you must uniquely identify the database by DBID for the restore operation. This requires determining the correct DBID for your database, and then using the SET DBID command to identify the target database before the RESTORE CONTROLFILE command, as shown in the following example:

Start RMAN and connect to the target database.

Run the STARTUP FORCE NOMOUNT command.

Run the SET DBID command to distinguish this connected target database from other target databases that have the same name.

Run the RESTORE CONTROLFILE command. After restoring the control file, you can mount the database to restore the rest of the database.

See Also:

Oracle Database Backup and Recovery Reference for more details on the use of SET DBID.

Restoring a Backup Control File By Using the DBID

To set the DBID, connect RMAN to the target database and run the following SET command, where target_dbid is the value you obtained from the previous step:

SET DBID = target_dbid;

To restore the control file to its default location and then mount it, run:

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;

To restore and recover the database, run:

RESTORE DATABASE; 
RECOVER DATABASE
  # optionally, delete logs restored for recovery and limit disk space used
  DELETE ARCHIVELOG MAXSIZE 2M; 

Recovering a Lost Datafile Without a Backup: Example

RMAN can handle lost datafiles without user intervention during restore and recovery. When a datafile is lost, the possible cases can be classified as follows:

  • The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then RESTORE creates the datafile in the original location or in a user-specified location (for example, with SET NEWNAME). The RECOVER command can then apply the necessary logs to the datafile.

  • The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.

In this example, the following sequence of events occurs:

You make a whole database backup of your ARCHIVELOG mode database.

You create a tablespace history containing a single datafile called /mydb/history01.dbf.

You populate the newly created datafile with data.

You archive all the active online redo logs.

A user accidentally deletes the datafile history01.dbf from the operating system before you have a chance to back it up.

In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:

# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE history;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";