Topics | How To | Full System Restore | Troubleshoot | Related Topics
Restore Considerations for this Agent
The Oracle iDataAgent supports the following types of restores:
Recovery involves two processes: restoring the physical datafiles, and then recovering the database. After the necessary files are restored, the database will be recovered.
Additionally, the Oracle 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 iDataAgent restore operations can be performed from the client, iDataAgent, 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.
See Also:
The duplicate database feature allows you use backups of the target database to create either of the following:
Prior to creating a duplicate database, you need to perform the Prerequisite Setup Steps for Creating a Duplicate Database.
The creation of a non-standby duplicate database or standby database can be in-place on the same physical computer, or out-of-place on another computer. Furthermore, you have the choice of whether or not to configure the Oracle SID in the CommCell Console as part of this operation. See the How To page for step-by-step procedures on creating a duplicate database or a standby 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 iDataAgent, you must use an appropriate restore procedure provided in the How To page to restore the Recovery Catalog.
When an Oracle restore job is submitted from the CommCell Console, the system will automatically check to ensure that the database is in a valid mode for the type of restore you are performing. If the database is not in the correct mode, the system will display a pop-up message informing you of this issue, at which point you can choose to either allow the system to automatically switch the database to the correct mode for the restore, or cancel the restore request and set the mode manually.
Automatic mode switching during Oracle restores is supported under the following conditions:
Also note that this feature is only supported when the CommServe and Oracle client are both at the current software release version. For mixed mode environments, if a restore is attempted while the database is OPEN, the system will still issue a pop-up message indicating it will automatically switch the database into MOUNTED mode. However, since it is not supported in this scenario, you will need to manually switch the database into MOUNTED mode.
The Oracle iDataAgent on Unix can detect whether multiplexing was used during backups from which data is being restored and then automatically multiplex the data streams during restore. This allows restore jobs to maximize the throughput of available data channels by multiplexing multiple data streams, which speeds up the process of restoring data. In order to fully optimize the multiplex restore capability, we recommend setting the number of restore streams to the same number of streams used by the backup job. In the event that you would like to disable the automatic multiplexing of restores, this can be accomplished by creating the sDisableMultiplexRestore registry key with a value of Y.
For more information, see Data Multiplexing.
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.
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 current subclient configuration or selected restore options will yield the desired result in the script. The script text can be previewed from the Subclient Properties 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.
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 following 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)
By default, the Oracle 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 iDataAgent. See Support Information - Restore Options - Restore Destinations for a list of Agents supporting each restore destination type.
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.