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

Part Number B14191-02
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
View PDF

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.

  1. 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;
    
    
  2. 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
    
    
  3. 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;
    
    
  4. 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';
    
    
  5. 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:

  1. Start RMAN and connect to the target database.

  2. Run the STARTUP FORCE NOMOUNT command.

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

  4. 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:

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

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

  3. You populate the newly created datafile with data.

  4. You archive all the active online redo logs.

  5. 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";