Topics | How To | Full System Restore | Troubleshoot | Related Topics
Restore Considerations for this Agent
The following page describes the agent-specific restore options. Additional restore options are accessible from the Related Topics menu.
The Oracle RAC iDataAgent allows you to perform parallel restores across multiple RAC nodes as a matter of design. Unlike other agents, this agent requires just one subclient and one storage policy per type used (i.e., data, log) along with the requisite number of allocated streams to perform parallel restores. As such, you can load-balance your restores across all or selected nodes of your RAC database and thereby take advantage of the strengths of each node.
The Oracle RAC iDataAgent supports the following types of restores:
Additionally, the Oracle RAC iDataAgent supports:
All restores can be performed in-place, out-of-place or cross-platform. (See Restore Destinations below for comprehensive information.)
For the Oracle RAC iDataAgent restore operations can be performed from the client and instance levels in the CommCell Browser.
When there is a problem with the Oracle database server or the operating system of the client computer full system restores may be required. See Restore Data - Oracle or Oracle RAC - Full System Restore for more information.
The duplicate database feature allows you use backups of the target database to the following:
Prior to creating a duplicate database, you need to perform the Prerequisite Setup Steps for Creating a Duplicate Database.
See the How To page for step-by-step procedures on creating a duplicate database.
The No Re-do Logs option, available from the Options tab in the Oracle Advanced Restore Options dialog, allows you to perform a point-in-time restore of a database that was backed up in NOARCHIVELOG mode. When enabled, RMAN suppresses the application of archived re-do logs so that only data from incremental backups are applied. If you do not specify noredo, RMAN will search for archived re-do logs after applying incremental backup data, and will issue an error message when it does not find them.
In order to perform Oracle command line restores on a Unix cluster, you need to use the following syntax for the allocate command within the RMAN script:
allocate channel ChannelName type ‘sbt_tape’ PARMS=”ENV=(CVOraVMName=VirtualMachineName)”;
where ChannelName can be chN (N is a stream number: 1, 2, ...) and VirtualMachineName should be the name of the virtual machine.
The method that you use to restore the Recovery Catalog depends on the method that you have used to back up the Recovery Catalog.
If you have exported the Recovery Catalog using the exp command, you must import the Recovery Catalog into a new database using the imp command.
If you have backed up the Recovery Catalog using the Oracle RAC iDataAgent, you must use an appropriate restore procedure provided in the How To page to restore the Recovery Catalog.
| You can recover an Oracle 9i database to a previous incarnation when using the recovery catalog. |
You can retrieve the database incarnation value using the RMAN command LIST INCARNATION.
If this option is de-selected (default) for a restore job, and if either a backup piece is inaccessible (because it has been deleted from the database or the MediaAgent is offline) or a block in the backup is corrupted within the latest full backup, RMAN automatically searches for another usable copy of this backup piece in the same library or another library. If no usable copies are available, RMAN starts searching all prior backups for the most recent available backup that is usable for the current job until it has exhausted all possibilities.
If this option is selected for a restore job, this will prevent job delays caused by RMAN trying to locate another copy of the backup data to complete the restore operation.
You can restore and recover individual database tables from non-system tablespaces to the same database or to another database. During a table restore, Calypso identifies the list of tablespaces that contain the actual data, and it restores the data and the system tablespaces to a staging path in an auxiliary Oracle instance, which either you or Calypso must create. You can use the CommCell Console to export the data from the auxiliary instance and import it to a destination that you choose, or you can leave the data in the staging path and import the data manually by using Oracle import utilities.
In order to restore individual Oracle or Oracle RAC database tables, you need to select the Enable Table Browse option in the Subclient Properties dialog for the subclient prior to a backup. Note that this option can be enabled on only one subclient. Also, ensure that this option is not enabled on the LOGS-only subclient. When this option is enabled, information such as Oracle tablespace, user ID and table name mappings are stored in the CommServe during the backup operation. When you browse for backup data, you can select the Table View option in the Browse Options dialog to view the list of database tables of each user in a tree view and select multiple tables to restore them to a destination location.
If you want to create the auxiliary instance for the restore, you must select the Auxiliary Instance option from the Oracle Restore Options (Table Restore) tab, and you must specify the auxiliary database name and PFile location along with the staging path information by populating the appropriate fields. If you create the auxiliary instance, you can specify the location of the instance either on the same client or on a different client by providing the appropriate information in the Database Client field. The auxiliary instance should be started in the NOMOUNT mode. See Prerequisite Setup Steps for Creating a Duplicate Database for information on creating the auxiliary database on the destination host.
On the other hand, to allow the system to create the auxiliary instance, do not select the Auxiliary Instance option. In such a case, Calypso will create the auxiliary instance with tsrst<jobid>, where jobid is the ID number for the restore job. If Calypso creates the auxiliary instance, the instance is by default included on your local computer. Since Calypso will connect to the auxiliary instance using "/", ensure that the source instance does not include "/".
For step-by-step instructions on running a table restore, see Restore and Recover One or More Database Table(s).
Oracle and Oracle RAC iDataAgents enable you to restore archive logs using the Restore Archive Logs option in the Advanced Restore Options (Restore) tab from the CommCell Console. You can restore all the archive logs or logs based on log time or Log Serial Number (LSN).For step-by-step instruction on restoring archive log files, see Restore Archive Log Files.
Before performing any restore procedures for this agent, review the following information.
You can preview the backup and restore scripts that will be submitted to RMAN to back up or restore data on a client. Previewing the script before running a backup or restore is useful for identifying whether the selected backup or restore options will yield the desired result in the script. The script text can be previewed from the Backup Options and Restore Options dialogs, and provides the capability for you to copy the text from the display window for manual submission in RMAN, if desired.
See Preview a Script for step-by-step instructions.
This is important if the archive logs are located only on the local disk. In such a case, unless you complete one of the recommended actions, the archive logs will be accessible only from the corresponding node, and log file restores initiated by any other node will fail.
You can run a validate job to ensure the integrity of the data and availability of the media before actually running a backup or restore job. When the validate option is selected on the Subclient Properties (Backup Arguments) tab or Advanced Restore Options (Options) tab, this will cause the system to simulate either a backup or restore job without using any media or over-writing the Oracle database. After the validate job completes, you can view the log file for the job to identify and correct any validation issues prior to running the backup or restore.
For step-by-step instructions, see Validate a Backup or Restore.
In the event that you need to restore the backup repository contained in the control file when the control file is lost and the recovery catalog is either lost or was never used, and you have previously configured autobackup of control files, then follow the procedure to Restore Control Files from Autobackup.
Review Performance Tuning - Oracle or Performance Tuning - Oracle RAC for details on setting configuration parameters to optimize backup and restore operations for your site.
When restoring an Oracle SP file from Autobackup, make sure that the database is in NOMOUNT mode. To start the database in NOMOUNT mode you need to do the following:
Startup force nomount
This command can be used only if you have the initSID.ora file in the below location:
- $ORACLE_HOME/dbs for Unix (can be copied from $ORACLE_HOME/admin/<instancename>/spfile folder)
- $ORACLE_HOME/database for Windows (can be copied from $ORACLE_BASE/admin/<instancename>/spfile folder)
If the database is upgraded, the next backup that is run detects the new version. The version is refreshed and displayed in the instance Properties dialog box and for the SQL Server iDataAgent, it is displayed during a browse operation. For more information, see Browse Databases.
When recovering an Oracle or Oracle RAC database with flashback enabled, make sure to disable the flashback option prior to recovery of the database, or else the recovery operation may fail. To disable the flashback, do the following:
alter database flashback off
Consider the following when performing a table restore operation:
If you are trying to recover an entire database, tablespaces, or data files for this agent, and if an error message advising you how to administer the Open DB option from the CommCell Console is displayed, simply ignore the message. However, ensure that the database is in mount mode.
When restoring backups with recovery catalog, the connect string details provided in the Instance Properties (Details) tab will be automatically displayed in the Restore Options (General) tab.
By default, the Oracle RAC iDataAgent restores data to the client computer from which it originated; this is referred to as an in-place restore. You can also restore the data to another Client computer in the CommCell. Keep in mind the following considerations when performing such restores:
The following section enumerates the types of restore destinations that are supported by the Oracle RAC iDataAgent. See Restore/Recover/Retrieve Destinations - Support for a list of Agents supporting each restore destination type. Also, the following table summarizes some restore destination capabilities for the agent.
| Restore Type | CommCell Console | Command Line |
| In-place from RAC to RAC | X | X |
| Out-of-place from RAC to standalone Oracle computer | X | X |
| Out-of-place from RAC to RAC | X | X |
| Duplicate RAC
(From RAC to standalone Oracle computer only) |
X | X |
For the Oracle and Oracle RAC iDataAgents, one of the options available during a restore operation is the ability to redirect datafiles and tablespaces to be restored to a new location. Additionally, datafiles and tablespaces can be renamed during restore. Both of these operations can be performed from the Redirect tab in the Oracle Advanced Restore Options dialog box. Redirecting and/or renaming datafiles and tablespaces as they are restored allows them to be restored without overwriting existing datafiles and tablespaces. This is also useful when restoring and recovering an Oracle database to a new host with a different directory structure. While redirecting the tablespaces/datafiles, it is always recommended that you redirect all of the restored tablespaces/datafiles. In other words, restore only the tablespaces/datafiles that need to be redirected.