RMAN Restore and Recovery Examples

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.

SET DBID = target_dbid;

RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;

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