Restoring backups on primary storage

Contributors Download PDF of this page

You can use the backup restore command to restore a database backup on primary storage.

SnapManager attempts to perform a volume-based, fast restore by default and provides eligibility check information. You can override some eligibility checks, if needed. If you are certain that a backup cannot be performed by using a fast restore, you can disable the fast restore eligibility check and perform a file-based restore.

You can use the backup restore command options to specify whether SnapManager should restore all or part of the backup. SnapManager also allows you to restore control files along with the data files or tablespaces from the backups in a single user operation. You can include -controlfiles with -complete to restore control files along with tablespaces and data files.

You can select one of the following options to restore the backup:

If you want to restore…​ Use…​

The entire backup with all tablespaces and data files

-complete

The list of specific tablespaces

-tablespaces

Specific data files

-files

The control files only

-controlfiles

Tablespaces, data files, and control files

-complete -controlfiles

You can also restore the backup from an alternate location by specifying -restorespec.

If you include -recover, you can recover the database to:

  • The last transaction that occurred in the database (all logs)

  • A specific date and time

  • A specific Oracle System Change Number (SCN)

  • The time of the backup (no logs)

  • Restore only

Note Both date and time recovery and the SCN recovery are point-in-time recoveries.

SnapManager (3.2 or later) provides the ability to recover the restored database backups automatically by using the archive log files. Even if the archive log files are available in the external location, if you specify the -recover-from-location option, SnapManager uses the archive log files from the external location to recover the restored database backups.

SnapManager provides the external location to Oracle. But, Oracle does not identify the files from the external destination. This behavior is noticed in flash recovery area destinationand the Automatic Storage Management (ASM) destination. These are issues with Oracle and the workaround is to always have backup of archive log files in such database layouts.

If any inconsistent SCN or date is provided, then recovery will stop at the last consistent point recovered with the error message Recovery succeeded, but insufficient. You have to manually perform recovery to a consistent state.

For recovery when no logs are applied, SnapManager recovers until the last SCN of the last archive log file created during the backup. If the database is consistent until this SCN, then the database will be opened successfully. If the database is not consistent at this point, SnapManager still attempts to open the database, which will be opened successfully, if the database is already consistent.

Note SnapManager does not support recovering the archive log-only backups.

If the archive log destinationon an NFS mount point, is not a Snapshot-capable storage, SnapManager enables you to recover the restored database backups using the profile. Before performing SnapManager operations on non-Snapshot-capable storage, you should add the destinations for archivedLogs.exclude in smo.config.

You must ensure that you set the exclude parameter before creating a profile. Only after setting the exclude parameter in the SnapManager configuration file, the profile creation is successful.

Note If the database is a non-Snapshot capable storage on an ASM disk group, and when the database is selected as an archive log destination, SnapManager does not support restoring the backups by using the profile.

If the backup is already mounted, SnapManager does not mount the backup again and uses the already mounted backup. If the backup is mounted by a different user, and if the current user does not have access to the previously mounted backup, other users have to provide the permissions. All the archive log files have read permissions for the groups owners; the current user might not get the permissions, if the backup is mounted by a different user group. The users can give permissions to the mounted archive log files manually and then retry the restore or recovery.

Recovering database backups in a Real Application Clusters (RAC) environment

During recovery of the database backups in a RAC environment, when the required archive log file is not found, Oracle requests for archive log files, and switches between different thread and change number in the RAC database. SnapManager for Oracle tries to recover the database as a best effort. The successful recovery of the database backups in the RAC environment depends on the availability of the archive log files in the backups.

The recommended recovery mechanism for the RAC database is as follows:

  • Ensure that all the archive log files are available in the backups or all the archive log files are available in the one external archive log destination.

  • If multiple external archive log destinations are provided, you can provide overlap of the archive log files while specifying the external archive log destinations for all the threads.

    For example, the external archive log location - I can have 1 to 100 archive log files, the external archive log location - II can have 98 to 200 archive log files, and the external archive log location - III can have 198 to 300 archive log files.

  • While pruning the archive log files, instead of deleting all the archive log files, you can delete the archive log files until SCN or date so that the backups can have same archive log files.

You can specify the -dump option as an optional parameter to collect the dump files after the successful or failed restore operation.

  1. Enter the following command:smo backup restore -profile profile_name-label label-complete-recover -alllogs [-recover-from-locationpath [,path2]]-dump-verbose

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 - complete -recover -alllogs -verbose

  2. To restore data for different scenarios, complete one of the following:

    If you want to restore…​ Command Example

    Complete database without control files and recover to a particular SCN number (3794392). In this case, the current control files exist, but all the data files are damaged or lost. Restore and recover the database from an existing full online backup to a point immediately before that SCN.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -recover -until 3794392 -verbose

    Complete database without control files and recover up to a date and time.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -recover -until 2008-09-15:15:29:23 -verbose

    Complete database without control files and recover up to a data and time. In this case, the current control files exist, but all of the data files are damaged or lost or a logical error occurred after a specific time. Restore and recover the database from an existing full online backup to a date and time immediately before the point of failure.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -recover -until "2008-09-15:15:29:23" -verbose

    Partial database (one or more data files) without control files and recover using all available logs. In this case, the current control files exist, but one or more data files are damaged or lost. Restore those data files and recover the database from an existing full online backup using all available logs.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -files /u02/oradata/sales02.dbf /u02/oradata/sales03.dbf /u02/oradata/sales04.dbf -recover -alllogs -verbose

    Partial database (one or more tablespaces) without control files and recover using all available logs. In this case, the current control files exist, but one or more tablespaces are dropped or one of more data files belonging to the tablespace are damaged or lost. Restore those tablespaces and recover the database from an existing full online backup using all available logs.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -tablespaces users -recover -alllogs -verbose

    Only control files and recover using all available logs. In this case, the data files exist, but all control files are damaged or lost. Restore just the control files and recover the database from an existing full online backup using all available logs.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -controlfiles -recover -alllogs -verbose

    Complete database without control files and recover using the backup control files and all available logs. In this case, all data files are damaged or lost. Restore just the control files and recover the database from an existing full online backup using all available logs.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -using-backup-controlfile -recover -alllogs -verbose

    Recover the restored database using the archive log files from the external archive log location.

    smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -using-backup-controlfile -recover -alllogs -recover-from-location /user1/archive -verbose

  3. Review the fast restore eligibility checks.

    Enter the following command: smo backup restore -profile targetdb1_prof1 -label full_bkup_sales_nov_08 -complete -recover -alllogs -recover-from-location /user1/archive -verbose

  4. If the eligibility check displays that no mandatory checks failed and if certain conditions can be overridden, and if you want to continue with the restore process, enter the following: backup restore -fast override

  5. Specify external archive log locations by using the -recover-from-location option.

Related information