Restoring Oracle Tablespaces and Datafiles to a Point-in-Time

You can restore an Oracle 11gr2 or 12c tablespace to a point-in-time, using an in-place restore operation. Use a point-in-time restore to revert the tablespace or PDB to a state before an undesired transaction or before a point of failure.

Note

Cross-machine (out-of-place) tablespace restore operations for a point-in-time are not supported.

When you perform a point-in-time restore of a tablespace, the database does not need to be in the down state. Consequently, there is no down time for the production database.

When you restore a tablespace to a point-in-time, the Commvault software automatically creates an auxiliary instance, and then copies the database and tablespaces to that instance. The software stages the database and tablespaces, and then restores the tablespaces to the destination.

The Commvault software uses an Oracle managed auxiliary instance for the tablespace point-in-time restore. Oracle automatically cleans up the auxiliary instance after the restore successfully completes.

Before You Begin

  1. Perform a full backup with a subclient configured for Oracle datafiles and tablespaces.

  2. Verify that the staging path has enough free space for the datafile for the database, and the tablespaces.

  3. Verify that the that the destination path has enough free space for the tablespaces that you want to restore.

Procedure

  1. From the CommCell Browser, expand Client Computers > client > Oracle.

  2. Right-click the instance, point to All Tasks and then click Browse and Restore.

  3. Select Latest Backup and click Time Range.

  4. Select the Absolute Time, and then in the End Time area, enter the date and time.

    The default Time Zone is the client's time zone.

  5. In the right pane of the CommCell Browser window, select the datafiles and tablespaces to restore, and click Recover All Selected.

  6. Click Restore in place, and then click Next.

    The Oracle In Place Restore Options dialog box appears.

  7. Click Advanced.

    The Advanced Restore Options dialog box appears.

  8. To automatically move the database to the correct mode before the restore, on the Options tab, select the Switch Database Mode for Restore check box.

    Note

    If the database is in MOUNT mode (not in OPEN mode), then you do not need to select the Switch Database Mode for Restore check box because a change in mode is not required.

  9. On the Auxiliary Instance tab, specify the auxiliary instance information:

    1. Optional: In the PFile box, type the full path to the PFile that the software uses when it creates the instance.

      If you do not specify a pfile, the Commvault software automatically creates a file.

    2. In the Staging Path box, type the full path to the location where the software creates the auxiliary instance.

  10. Optional: Select the restore options.

    Set the Oracle Database ID

    The Oracle DBID is an internal, uniquely generated number that distinguishes the target database from the rest of the databases with the same name, in the recovery catalog. Oracle creates this number automatically when you create the database.

    You can use this option when:

    • There is no control file and you need to restore the control file or SP file from the autobackup

    • Multiple databases exist in the recovery catalog and you need to restore the control file

    On the Options tab, select the Set DBID check box.

    Open the database after the restore

    After a restore, set the Commvault software to automatically open the Oracle database. When the database is open, it records transactions.

    On the Options tab, select the Open DB check box.

    Reset the database and logs

    By default, the database is automatically set to open, and the logs are reset.

    If you reset the logs to an open state, you can then reset the database.

    On the Options tab, select the Reset Database check box and one of the following Reset Log options:

    • To open the database without the RESETLOGS option, select None.

    • To open the database with the RESETLOGS option, select Yes.

    • To open the database with the NORESETLOGS option, select No.

    Perform a point-in-time restore of a database that was backed up in NOARCHIVELOG mode

    If the database was backed up in NOARCHIVELOG mode, enable the redo logs.

    When the no redo log is disabled, RMAN searches archived redo logs after applying the incremental backup data during a restore. When you set No Redo Logs, RMAN restores the data from the incremental backup and not the archived redo logs.

    On the Options tab, select the No Redo Logs check box.

    Prevent RMAN failovers to the previous backup for Oracle 10g databases or higher

    Select this option if you want to increase the speed.

    During restore operations, RMAN automatically looks for another copy of the backup file under the following circumstances:

    • A backup piece is corrupted or deleted

    • A MediaAgent is offline

    • A block in the backup is corrupted within the latest full backup

    If another copy is not available in the other copy, RMAN uses an older version of the file. When multiple channels are available for the same device type, RMAN automatically retries on another channel and searches all prior backups until it has exhausted all possibilities.

    On the Options tab, select the Disable Oracle Channel Restore Failover check box.

    Validate the restore

    Validation verifies that the backup copies of the data and logs are intact and usable for restores. RMAN simulates the restore job without the media to determine whether the restore can be successfully performed.

    When a validate job is complete, you can view the job log files to identify and correct any issues.

    On the Options tab, select the Validate check box.

    Configuring Pre- and Post-Processes

    Run scripts before or after the restore.

    Enter the full path for the pre-recovery and post-recovery script.

    You can choose to run the post-process script even if the restore job failed. You can use the post-process script to bring a database online or to release a snapshot.

    To pass the database instance name to the script, see Passing the Instance Name to Pre and Post Scripts for Databases.

    On the Pre/Post tab:

    1. In the Pre-Recovery Command box, type the full path name for the script.

    2. In the Post-Recovery Command box, type the full path name for the script.

    3. To run the post recovery process regardless of the job's outcome, select the Run Post Process for all attempts check box.

    4. In Windows configurations, specify the user that runs the process, in the Pre/Post Impersonation section, select one of the options:

      if the local account has permission to execute the processes on the destination client, select the Use Local Accounts option.

      To impersonate another user with permission, select the Impersonate User option and enter the credentials.

    Restore from a copy precedence

    If the backup is corrupted, restore from a storage policy copy instead of the backup.

    For more information on modifying the copy precedence of a storage policy copy, see Copy Precedence.

    On the Copy Precedence tab, select the Restore from Copy Precedence number check box and enter a copy precedence number.

    Restore from a specific backup

    On the Restore tab, select the By Tag check box and enter the tag.

  11. Click OK to close the Advanced Restore Options dialog box.

  12. Optional: You can view or customize the RMAN script that is automatically generated from the selected options. For more information, see Viewing Oracle Restore RMAN Scripts and Customizing Oracle Restore RMAN Scripts.

  13. Click OK to close the Oracle In Place Restore Options dialog box and start the restore.

If your restore includes Oracle SYSTEM tablespaces, switch the database mode to MOUNT.

Loading...