Guidelines for when you can use fast restore
Suggest changes
PDFs
Specific rules apply for using fast restore to achieve optimal restore performance. In some cases, you cannot use fast restore.
To achieve optimal restore performance (volume restore or full disk group restore), you must adhere to the following rules:
-
Only complete restores of full backups are eligible for fast restore.
-
Only data files are eligible for fast restore.
-
Data files must be the only files in a volume to be eligible for fast restore.
Although temporary data files can reside in the volume, control files, logs, pfiles, or other files must reside on a separate volume from the data files. You must set up an Oracle database with data files on a separate volume from control files, archived logs, and online log files.
-
Data files for only one database must be present in the volume.
-
Multiple file systems can be used, but the files in those file systems must be data files for only one database.
-
SAP requires a slightly different file layout.
The “General layout and configuration” section contains details.
-
If
BRRESTOREis used to restore the database, fast restore is used with the fast parameter in the backup utility parameter file.
|
To check whether a previously created backup is restorable by using fast restore, you can use the -preview option of the smsap backup restore command.
|
The fast restore process cannot be used in the following cases:
-
On partial backups
-
On backups from the secondary storage if the backup also exists on the primary storage
You cannot restore these using the file-based or volume-based restore.
-
On backups protected with SnapVault
The fast restore process cannot be used for backups that were created earlier than the last protected backup. However, you can use the fast restore process for backups created after the last protected backup. For example, consider backups A, B, and C. B is the last backup to transfer to secondary storage by using SnapVault. You can fast restore B and C, but you cannot fast restore A because it was created earlier than the last protected backup. SnapVault needs a baseline SnapVault to compute the time difference and send to the secondary storage the next time a backup is transferred to the secondary storage. The last protected backup acts as the baseline Snapshot copy. Therefore, using the fast restore process prevents SnapVault from being able to recognize the baseline.
-
FlexClones or LUN clones that use Snapshot copies that were created after the Snapshot copy to which the volume is being reverted
For example, the clones can be the result of a later backup that is being mounted or being cloned by SnapManager.
-
LUNs that are not part of the active SnapDrive Snapshot copy
You cannot perform a fast restore along with other types of restores for the same backup. For example, if one data volume can be restored by using the fast restore process but another data volume cannot, neither is restored by using the fast restore process. You can choose a file-based restore in this case.
Additionally, you should consider the following points about database restores:
-
SnapManager never restores archive logs or redo logs but mounts the backup of archive log files and uses them for recovery.
-
SnapManager never restores control files by using volume restore.
-
If you want to restore control files and data files, SnapManager performs the restore in two steps.
SnapManager restores the control files first and then the data files.
-
If SnapManager finds temporary files in the same volume as the standard tablespace files, you do not need to issue an override to perform a volume-level restore.
After a volume restore, the TEMP tablespace is brought back online.
Both SnapManager for SAP and the BACKINT interface use the same logic when determining which restore mechanism can be used. All restore methods can be used whether the backup was taken with SnapManager for SAP or the BACKINT interface, and whether the restore is performed via SnapManager for SAP or the BACKINT interface.
Related information