| Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) Part Number B14192-03 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2) Part Number B14192-03 |
|
|
View PDF |
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.
This section contains the following topics:
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.
Note:
After restoring the control files of your database from backup, you must perform complete media recovery of the database as described in "Performing Media Recovery of a Restored Database, Tablespace or Datafile", and then open your database with the RESETLOGS option. The only exception is the case described in "Restore of the Control File to a New Location", where you restore your control file to a location not listed in the
CONTROL_FILES initialization parameter. In that case, you create a copy of your control file in the specified location without touching your running database.RMAN can restore the control file 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.
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.
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 Backup and Recovery Reference
See "Determining your DBID" for details on how to determine your DBID.
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 updates a control file restored from backup, by performing an implicit crosscheck of all disk-based backups and image copies listed in the control file, and cataloging any backups in the flash recovery area that are not recorded in the restored control file. As a result the restored control file has a complete and accurate record of all backups in your flash recovery area and any other backups that were known to the control file at the time of the backup. This improves the usefulness of the restored control file in the restoration of the rest of your database.
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 in this example:
RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;
Restoring a lost control file from autobackup is easier when using a recovery catalog than when using only the control file to store the RMAN repository. The recovery catalog contains a complete record of your backups, including backups of the control file. Therefore, you do not have to specify your DBID or control file autobackup format.
To restore the control file, connect RMAN to the target database and the recovery catalog, and bring the database to NOMOUNT state. Then issue the RESTORE CONTROLFILE command with no parameters, as in this example:
% rman TARGET rman/rman CATALOG catdb/catdb RMAN> RESTORE CONTROLFILE;
The restored control file is written to all locations listed in the CONTROL_FILES initialization parameter.
For more details on restrictions on using RESTORE CONTROLFILE in different situations, see the discussion of RESTORE CONTROLFILE in Oracle Database Backup and Recovery Reference.
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.
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.
After you restore your database using a backup control file, you must run RECOVER DATABASE and perform an OPEN RESETLOGS on the database.
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 Backup and Recovery Reference.
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, ?/dbs/spfile.ora on Linux).
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:
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.
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;
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;
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
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 Backup and Recovery Reference
See "Determining your DBID" for details on how to determine your DBID.
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 file system 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 a tablespace to its original location and performing media recovery on it is described in "Restore and Complete 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.
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';
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, note that channels must be configured in advance or a RUN block with ALLOCATE CHANNEL commands must be used to enable access to 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 Backup and Recovery Reference for more details on options for the RECOVER command.
This procedure restores a single datafile to a new location and perform media recovery on it. This lets you restore and recover if the old location is inaccessible because of a problem such as a media failure.
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 form of the command:
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.
RMAN will restore archived redo log files from backup automatically as needed to perform recovery.
However, you can also 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.
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:
After connecting to the target database, make sure the database is mounted or open.
Perform the following operations within a RUN block, as shown in the following example script:
Specify the new location for the restored archived redo logs using SET ARCHIVELOG DESTINATION.
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
.
.
.
}
You can specify restore destinations for archived logs multiple times in one RUN block, in order to distribute restored logs among several destinations. (You cannot, however specify multiple destinations simultaneously to produce multiple copies of the same log during the restore operation.) You can use this feature to manage disk space used to contain the restored logs.
This example restores 300 archived redo logs from backup, distributing them across the directories /fs1/tmp, /fs2/tmp, and /fs3/tmp:
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/tmp';
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
.
.
.
}
When you issue a RECOVER command, RMAN finds the needed restored archived logs automatically across the destinations to which they were restored, and applies them to the datafiles.
