When the database is corrupted or lost, you can restore and recover it from the latest offline or online full backup (depending on how the subclient was configured for backups).
By default, the database is restored to the same location from where it was backed up. Once the database is restored, it is recovered to the current time.
Use the following steps to restore and recover a database to the same host:
If the computer on which you hosted a database is damaged or destroyed, you can restore and recover the lost database with the same directory structure on to a new host.
By default, the database is restored in the ARCHIVELOG mode, You can also choose to restore the db in NOARCHIVELOG mode.
Use the following steps to restore and recover a database to a new host with the same directory structure:
If the computer on which you hosted a database is damaged or destroyed, you can restore and recover the lost database on a new host computer with a different directory structure. You can restore a database either in ARCHIVELOG or NOARCHIVELOG mode on a new host.
By default, the database is restored in the ARCHIVELOG mode, You can also choose to restore the db in NOARCHIVELOG mode.
Use the following steps to restore and recover a database to a new host with a different directory structure:
The point-in-time restore is useful in the following scenarios:
When you restore and recover an entire database to a previous point-in-time from an online backup or offline backup (depending on how the subclient was configured for backups) to the original host, it is recommended to use the control files.
When you perform a point-in-time restore for a database, the next scheduled backup for that database will automatically convert to a full backup. |
Use the following steps to restore and recover a database to a previous point-in-time:
If you have assigned unique identification tags for the data, you can restore and recover an entire database from a specific backup using the tags.
Use the following steps to restore the database with specific identification tags:
In addition to restoring a database, you can also restore specific tablespaces or datafiles that were lost due to an error or corruption. By default, the selected tablespaces/datafiles are restored to the original location from the latest online backup.
Use the following steps to restore the datafile(s) or tablespace(s):
By default, the control file will be automatically updated with the new location when you redirect tablespaces/datafiles to a new location. Use the following steps to redirect the tablespaces/datafiles to a new location without updating the control file:
|
|
|
|
If you have assigned unique identification tags during backups, you can restore from a specific backup using the tag. Use the following steps to restore the datafile(s) or tablespace(s) using a specific tag:
|
|
|
|
|
|
|
Archive logs can be restored separately or along with the database. Archive Log restores are useful in the following scenarios:
Use the following steps to restore all the archived logs (note that this is the default option):
|
|
|
When you browse between a specific point of time range, the logs pertaining to all the cycles within the specified time range will be listed.When restoring the archive logs based on the log time, if the data is also included in the restore, ensure that the point-in-time range for the restore is the same for both the data and logs.
If you are including the database in the restore, see point-in-time restore to restore the database to a specific point-in-time. Use the following steps to restore the logs to a specific log time:
|
|
|
Note the following when you restore the logs based on the log serial number:
Use the following steps to restore the log identified by a serial number:
|
|
|
If you have assigned unique identification tags during log backups, you can restore the logs using the tags.
Use the following steps to restore the logs with specific identification tags:
|
|
|
Control and SP files are required to recover a database to the current state. Restoring a control/sp file is useful in the following scenarios:
Ensure that the database is in NOMOUNT mode when you restore the control/sp files.
The database will be in MOUNT mode after you restore the control/SP file. |
Ensure that you have previously configured auto backup of control files to restore the control file from auto backup. Restoring a control file will destroy all the previous backups. Hence, you need to perform a full backup after you restore a control file.
By default, the Control/SP files are restored from the latest backup. Use the following steps to restore a Control/SP file from a latest backup:
|
If the control file and recovery catalog are lost, you can restore the control file from a specific backup piece using a backup piece number. (Backup piece references the backup of one or several database files)
You can obtain the backup piece value from the RMAN logs of the backup job. Use the following steps to restore a control/sp file from a specific backup:
|
|
|
If your database consists of multiple copies of control files, you can replace a corrupted control file by manually copying from an existing control file and restoring it.
Follow the steps given below to restore a control file from an existing control files:
SQL> shutdown
SQL> startup nomount;
If you are certain that the control file was corrupted, lost at or after a specific time, you can restore the control file to such a point-in-time.
Follow the steps given below to restore a control/sp file to a point-in-time:
|
|
|
By default, the Control file/SP File is restored to the original location. Use the following steps to restore the control files to a new location:
|
|
|
If auto backup format is customized other than the default format( ‘%F’), you can customize the RMAN Script to restore the controlfile/spfile from this custom format auto backup without catalog.
The custom format for auto backup is as follows:
RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name TEST are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'TEST_DB_%F'; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO 'TEST_DB_%F_CTRL'; CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHCONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
|
Oracle 12c supports container and pluggable databases. Calypso supports the restore of container and pluggable databases.
If you have backed up an entire container database you can restore the entire container database, a single pluggable database, or multiple pluggable databases.
Container databases can be restored like any full database. See Restoring and Recovering an Entire Database.
1. | Before running the restore, enter the following on the command line:
|
|
2. | Create and
customize
an RMAN script file on the client computer, where the last line in the
script specifies the pluggable databases to restore. The line has
the following format, with "pluggable_database_name1" through "pluggable_databaseN". Each database must be
separated by a "," and must be part of the backup. restore pluggable_pluggable_database_name1, ..pluggable_database_nameN; |
Example: RMAN script restoring the pluggable database
"SINGLE_PDB". run { restore pluggable database SINGLE_PDB ; } exit; Click here to see the RMAN log output for this example. |
3. | Execute the RMAN script. | See Running RMAN Scripts from Third Party Command Line. |
1. | Before running the restore, enter the following on the command line:
|
|
2. | Create and
customize
an RMAN script file on the client computer where the last line in the
script specifies the pluggable database to restore. The line has
the following format, with "pluggable_database_name1" through "pluggable_databaseN". Each database must be
separated by a "," and must be part of the backup. restore pluggable database pluggable_database_name1, ...pluggable_database_nameN; recover pluggable database pluggable_database_name1, ..pluggable_database_nameN; |
Example: RMAN script restoring the pluggable databases
"PLUG_DB1" and "PLUG_DB2". run { restore pluggable database PLUG_DB1, PLUG_DB2 ; recover pluggable database PLUG_DB1, PLUG_DB2; } exit; Click here to see the RMAN log output for this example. |
3. | Execute the RMAN script. | See Running RMAN Scripts from Third Party Command Line. |
By default, the database is recovered along with the restore. However, you can also restore the data and then recover the database at a later point-in-time.
You can recover a database to the current time either to the original host or to a different host. Use the following steps to recover a database to the current time:
|
|
|
You can apply archived logs and recover a database to a previous point-in-time where it is consistent and stable. Use the following steps to recover a database to a point-in-time:
|
|
|
|
|
The System Change Number (SCN) keeps track of the timing of transactions in the oracle database. The SCN's are stored in the control files and the datafile headers. You can recover the database to the last existing SCN number in the control file. (The last SCN number denotes the last consistent state of the database.)
Use the following steps to recover a database using SCN:
|
|
|
|
|
A duplicate (auxiliary) database is a copy or subset of the target database and has a unique DBID. It is independent of the primary database and can be registered in the same recovery catalog as the primary database. The duplicate database will be useful for testing and demo purposes.
If the duplicate (auxiliary) database already exists in the destination computer, it will be overwritten. Duplicate database is created from the full backup of the database with the logs. If you want the latest data in the duplicate database, make sure to perform a full backup with the log files before creating the duplicate database.
Use the following steps to create a duplicate database on a different host with the configured instance. Make sure that the instance is configured on a different host in the CommCell Console.
|
|
|
|
|
On Unix: $ORACLE_HOME On Windows: %ORACLE_HOME% |
|
|
|
On Unix: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/, source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) On Windows: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/', 'source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') (When using these parameters on a Windows computer, the file paths should be entered in uppercase.) |
|
|
|
|
|
DUPDB = DESCRIPTION = ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) ) ) |
|
$ lsnrctl reload |
|
Example: sys/sys@<SID name> |
|
|
|
|
|
In order to create duplicate database on a different host without a configured instance, we need the following installed on the destination computer:
Use the following steps to create a duplicate database on a different host without the configured instance. Make sure that the duplicate instance is not configured from the CommCell console.
|
|||
|
|||
|
On Unix: $ORACLE_HOME On Windows: %ORACLE_HOME% |
||
|
|||
|
On Unix: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/, source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) On Windows: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/', 'source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') (When using these parameters on a Windows computer, the file paths should be entered in uppercase.) |
||
|
|||
|
|||
|
DUPDB = DESCRIPTION = ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) ) ) |
||
|
|||
|
Example: sys/sys@<SID name> |
||
|
|||
When using a different host without configuring an instance, the install path in the source and destination clients
must be the same. Use the following steps to set the same install path
in the source and destination clients.
|
|||
|
|||
|
|||
|
Use the following steps to create a duplicate database on the same host without the configured instance:
|
|
|
|
|
On Unix: $ORACLE_HOME On Windows: %ORACLE_HOME% |
|
|
|
On Unix: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/, source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) On Windows: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/', 'source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') (When using these parameters on a Windows computer, the file paths should be entered in uppercase.) |
|
|
|
|
|
DUPDB = DESCRIPTION = ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) ) ) |
|
|
|
Example: sys/sys@<SID name> |
|
|
|
|
|
Use the following steps to create a duplicate database on the same host with the configured instance:
|
|
|
|
|
On Unix: $ORACLE_HOME On Windows: %ORACLE_HOME% |
|
|
|
On Unix: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/, source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) On Windows: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/', 'source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') (When using these parameters on a Windows computer, the file paths should be entered in uppercase.) |
|
|
|
|
|
DUPDB = DESCRIPTION = ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) ) ) |
|
|
|
Example: sys/sys@<SID name> |
|
|
|
|
|
By default, the read only tablespaces are not verified for consistency and are restored from the backup. You can skip the consistent tablespaces and restore the tablespaces that are not consistent or missing. This will save the time taken for the restore.
Use the following steps to exclude read only table spaces during restore:
|
|
|
By default, a duplicated database is opened without any restricted access. If necessary, you can open the db in restricted mode for administrative tasks. This will restrict access to other users.
Use the following steps to open the duplicate database in restricted mode:
|
|
|
While creating a duplicate database, you can exclude some tablespaces from the duplicate database. Use the following steps to exclude the tablespaces from the duplicate database:
|
|
|
You can create online redo logs for duplicate database and apply them to restore the database in case of corruption. Use the following steps to create an online redo log file:
|
|
|
By default, groups are created to include specific online redo log members. Use the following steps to add specifications for each of these online redo log groups:
|
|
|
By default, when you create a standby database, RMAN will verify the target datafiles for duplicate files (files sharing the same names). This verification job may consume more time. Hence, use the following steps to prevent RMAN from performing this verification:
|
|
|
Standby databases are useful when a primary database experiences a disaster such as hardware related failure or data corruption and it is not configured for a cluster failover. A standby database is a replicated copy of the primary database. It is updated by applying archived redo logs from the primary database. A standby database will not have a unique DBID.
Use the following steps to create a standby database on a different host without the configured instance:
|
|
|
LOG_ARCHIVE_DEST_1='LOCATION= C:\Oracle\Oradata\TSH1\Archive MANDATORY REOPEN=30' LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR SYNC AFFIRM' |
|
*.log_archive_dest_1='LOCATION=/
LOCATION_OF_DESTINATION_DB_ARCHIVELOG /arch'
*.STANDBY_ARCHIVE_DEST='/ LOCATION_OF_STANDBY_DB_ARCHIVELOG /stdbyarch' *.STANDBY_FILE_MANAGEMENT=auto DB_FILE_NAME_CONVERT=('/DATA_FILE_PATH_ON_SOURCE_MACHINE/stdby', '/ORACLE_DATA_FILE_PATH_ON_STANDBY_MACHINE/stdby/') LOG_FILE_NAME_CONVERT=('/ DATA_FILE_PATH_ON_SOURCE_MACHINE /stdby', '/ ORACLE_DATA_FILE_PATH_ON_STANDBY_MACHINE /stdby/') |
|
On Source computer:
<Standbydb1_use_diff_connection_string> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = destination_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_use_same_db_name_as_primary>) ) ) <Standbydb_primary> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = primary_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_same_as_destination><) ) ) On standby computer: <standbydb1_destination_connection_string> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = destination_standby_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_destination_db_name_same_as_primary>) (UR = A) ) ) <standbydb_primary_connection> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = primary_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_primary_db>) ) ) |
|
|
|
|
When using a different host without configuring an instance, the install
path in the source and destination clients must be the same. Use the following steps to set the same install path in the source and destination clients:
|
|
|
|
|
|
|
DB_FILE_NAME_CONVERT= '<primary_database_temp_datafile_old _location>', '<standby_database_temp_datafile_new_location>' |
Creating a standby database |
|
|
|
|
|
|
Use the following steps to create a standby database on a different host with the configured instance:
Setting up a Standby database: | |
|
|
|
LOG_ARCHIVE_DEST_1='LOCATION=C:\Oracle\Oradata\TSH1\Archive
MANDATORY REOPEN=30' LOG_ARCHIVE_DEST_2='SERVICE=stby1 LGWR SYNC AFFIRM' |
|
*.log_archive_dest_1='LOCATION=/
LOCATION_OF_DESTINATION_DB_ARCHIVELOG /arch'
*.STANDBY_ARCHIVE_DEST='/ LOCATION_OF_STANDBY_DB_ARCHIVELOG /stdbyarch' *.STANDBY_FILE_MANAGEMENT=auto DB_FILE_NAME_CONVERT=('/DATA_FILE_PATH_ON_SOURCE_MACHINE/stdby', '/ORACLE_DATA_FILE_PATH_ON_STANDBY_MACHINE/stdby/') LOG_FILE_NAME_CONVERT=('/ DATA_FILE_PATH_ON_SOURCE_MACHINE /stdby', '/ ORACLE_DATA_FILE_PATH_ON_STANDBY_MACHINE /stdby/') |
|
On Source computer:
<Standbydb1_use_diff_connection_string> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = destination_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_use_same_db_name_as_primary>) (UR = A) ) ) <Standbydb_primary> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primary_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_same_as_destination><) ) ) On standby computer: <standbydb1_destination_connection_string> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = destination_standby_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_destination_db_name_same_as_primary>) (UR = A) ) ) <standbydb_primary_connection> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primary_host_name)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <standbydb_primary_db>) ) ) |
|
|
|
|
|
|
|
|
|
DB_FILE_NAME_CONVERT='<primary_database_temp_datafile_old _location>','<standby_database_temp_datafile_new_location>' |
Creating a Standby Database: | |
|
|
|
By default, the database tables can be restored from an online full backup, provided the table browse was enabled in the associated subclient before performing the backup. See Enabling Table Browse for Restores for information on configuring the subclient for table browse.
When restoring database tables, by default an auxiliary instance is automatically created. Hence, make sure that there is enough disk space on the client for the auxiliary instance.
If some of the tables in the database are lost or corrupted, you can restore those tables back to the same database using the following steps:
|
|
|
|
|
Use the following steps to restore tables to a different database on the same host:
|
When restoring the tables to a different host, ensure the following:
For example:
// db1_table = <--- Name of the source database
db1_table =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = M1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db1)
)
)
//db1 = <--- Name of the destination database
db1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = M2)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = db1)
)
)
Use the following steps to restore the tables to a different host:
|
When the selected database client is not the source on a Table Restore, you must select the Auxiliary Instance and provide a user defined Auxiliary database name. If you do not do this, the Auxiliary database is created on source client itself and the selected database client is ignored.
By default, when you restore database tables to a target instance, the system automatically duplicates the source database to an auxiliary instance in a temporary staging location specified during the restore operation. The database will be automatically imported from this auxiliary instance after the restore.
Use the following steps to set up a specific database as an auxiliary instance. This is useful when you want to restore a table to a specific failure point.
1. | Copy the init<SID>.ora file from the source database to the auxiliary database instance. | |
2. | Update the database name and the database file locations in the init<SID>.ora file for the auxiliary database instance. | |
3. | Add the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters in the init<SID>.ora file. These parameters will redirect the datafiles, temp files, and log files to the auxiliary instance. |
Windows
Clients: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/','source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') Unix Clients: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/,source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) |
4. | Add the log_archive_dest_1 parameter is added to the init<SID>.ora file on the auxiliary instance. | |
5. | Restart the Oracle Services, if using Windows clients. | |
6. | Add the destination instance name in the Listener.ora and Tnsnames.ora files. If using a different host, add the duplicate database instance name in the Listener.ora file on the destination host and Tnsnames.ora files on the destination and source hosts. Also, add the original database name in the Tnsnames.ora file on the destination host. |
DUPDB = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) (UR=A) ) ) |
7. | Restart the Listener. | $lsnrctl reload |
8. | Ensure that the auxiliary instance is in NOMOUNT mode. | sql> startup nomount; |
By default, when you restore database tables to a target instance, the system automatically duplicates the source database to an auxiliary instance in the specified temporary staging location. Once the database is duplicated, you can import the tables to the target instance.
However, if required, you can also use an user-defined auxiliary instance for the restore operation. This is used when you want to restore a table to a specific failure point.
When restoring tables to a different host, if a user-defined auxiliary instance option is selected for the restore, you need to recover the database to a specified point-in-time or SCN number. You cannot recover the database to the current time using an user-defined auxiliary instance. |
1. | Copy the init<SID>.ora file from the source database to the auxiliary database instance. | |
2. | Update the database name and the database file locations in the init<SID>.ora file for the auxiliary database instance. | |
3. | Add the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters in the init<SID>.ora file. These parameters will redirect the datafiles, temp files, and log files to the auxiliary instance. |
Windows
Clients: DB_FILE_NAME_CONVERT=('sourcE_of_df_path/','dup_of_df_path/','source_of_temp_path/','dup_of_temp_path/',...) LOG_FILE_NAME_CONVERT=('source_of_log_path/redo','dup_of_log_path/redo') Unix Clients: DB_FILE_NAME_CONVERT=(source_of_df_path/,dup_of_df_path/,source_of_temp_path/,dup_of_temp_path/,...) LOG_FILE_NAME_CONVERT=(source_of_log_path/redo,dup_of_log_path/redo) |
4. | Add the log_archive_dest_1 parameter is added to the init<SID>.ora file on the auxiliary instance. | |
5. | Restart the Oracle Services, if using Windows clients. | |
6. | Add the destination instance name in the Listener.ora and Tnsnames.ora files. If using a different host, add the duplicate database instance name in the Listener.ora file on the destination host and Tnsnames.ora files on the destination and source hosts. Also, add the original database name in the Tnsnames.ora file on the destination host. |
DUPDB = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = powerpc02)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dupdb) (UR=A) ) ) |
7. | Restart the Listener. | $lsnrctl reload |
8. | Ensure that the auxiliary instance is in NOMOUNT mode. | sql> startup nomount; |
|
|
|
|
|
By default, the system generated auxiliary instance is deleted automatically once the tables are imported to the destination instance.
Use the following steps to disable the clean-up of auxiliary instance after the restore:
|
By default, you can restore the tables with english characters. Use the following steps to restore the non-english characters in the tables:
|
During table restores, the tables are exported from the auxiliary instance to the destination client and later imported to the target database. By default, the following data objects are exported along with the tables:
However, the stored procedures associated with the selected tables are not exported by default. Use the following steps to export the stored procedures and additional export parameters, such as (COMPRESS or PARALLEL):
Stored procedures are restored from the Schema level. Schema is the collection of data objects created by the user to contain or reference their data. Hence, if one of the table within the schema is selected for restore, all the stored procedures for that schema will also get restored. |
When exporting the tables, the datapump export utility is used if it is supported by the Oracle application. The datapump utility facilitates the export of stored procedures. In oracle versions that do not support datapump export utility, you will not be able to include stored procedures during export.
|
When you browse using the table view, you can also view the dependent and referenced tables associated with the tables selected for the restore.
Dependent tables are the parent tables (containing the primary key) that the selected table (containing the foreign key) depends upon. Similarly, Referenced tables are the child tables (containing the foreign key) that references the selected table (containing the primary key).
By default, all the dependent and referenced tables will be included in the restore operation. Use the following steps to exclude the dependent/referenced tables:
|
When restoring tables, you can include recursive dependency relationship of all the dependent/referenced tables.
Use the following steps to include all the dependent/referenced tables recursively:
|
By default, the restore operation will overwrite the existing tables in the destination database during the restore. You can also configure the restore operation to delete the existing tables before performing the restore.
Manually drop/delete the existing tables at the destination instance and then import the tables.
Use the following steps to automatically delete existing tables on the destination instance during restore. Note that you can also manually drop/delete the existing tables at the destination instance and perform the restore without enabling this option.
|
You can perform restores of one of more databases from the command line interface.
Command line restores enable you to perform restore operations on multiple clients at the same time. It also allows you to reuse the command line scripts for additional restores.
When performing command line restores, note that backups taken from the CommCell Console can be restored using Command Line and vice versa. However, backups taken from a previous version of the CommCell Console can be restored only from the Command Line.
In order to run the restores from command line, you need an input xml file which contains the parameters for configuring the restore options. This input xml file can be obtained using one of the following ways:
To run command line operations you must first login to the CommServe as follows:
qlogin -cs <commserve name> -u <user name>
qlogin -cs server1 -u user1
qoperation execute -af restore_template.xml -clientName xxxxx -instanceName xxxxx
qlist job –j JOBID
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
Restoring from a Current Backup |
qoperation execute -af restore_template.xml -clientName client1 -instanceName instance1 |
Restoring Databases to a Point in Time |
qoperation execute -af restore_template.xml -clientName client1 -instanceName instance1 -toTimeValue '2011-11-28' |
You can also submit RMAN scripts from the Command Line Interface using Qcommands. The RMAN scripts are submitted through argument files. This method enables you to take advantage of the CommServe's job management and reporting capabilities as well as media reservation, multi-streaming and storage policies.
When you submit RMAN scripts using qcommands:
1. |
Create the RMAN Script file for the restore operation. Ensure that you create separate RMAN scripts for the data and logs |
run {
allocate channel ch1 type 'sbt_tape' PARMS="BLKSIZE=262144" ; allocate channel ch2 type 'sbt_tape' PARMS="BLKSIZE=262144" ; restore database ; recover database; sql "alter database open"; } |
2. | Create the argument file. |
For example,
[oraclerestorescript] /rman_restore.scr |
3. | Login to the Commserve from the command prompt. |
For example: qlogin -cs server1 -u user1 |
4. | Run the qoperation restore command. |
Example: qoperation restore -sc client1 -a Q_ORACLE -i instance1 -af /argfile2.txt |
Parameter | Usage | Description |
[oraclerestorescript] |
[oraclerestorescript]
<filename> Example: [oraclerestorescript] restorelogs.txt |
Name of the file that contains RMAN script for restore. |
[rmanlogfile] |
[rmanlogfile]
<ouputfile location>/<outputfile name> Example: [rmanlogfile] /usr/temp1 Here, temp1 is the directory and not the file name. |
This is an optional parameter. Location where the RMAN restore output file will be saved and the name of the output file. By default, an output file restore.out is created in the job results directory. You can change the name of the output file as well as the location using this parameter. In order to include the JOB ID in the output file name, you need to set the sQcmd_Rst_RmanLogFile registry key. |
[options] | QR_DO_NOT_USE_ORA_CONNECT_STRING |
This is an optional parameter. If specified, the restore operation will use the user defined connect string and catalog connect values specified in the RMAN script will be used instead of the values specified in the Instance Properties (Details) tab in the CommCell Console. |
[mediaagent] |
[mediaagent]
<mediaagentname> Example: [mediaagent] MA1 |
This is an optional parameter. Name of the MediaAgent to be used for the restore job. |
[library] |
[library]
<libraryname> Example: [library] LN1 |
This is an optional parameter. Name of the library to be used for the restore job. |
[drivepool] |
[drivepool]
<library_name>/<drivepool_name> Example: [drivepool] LN1/DP1 |
This is an optional parameter. Name of the drivepool in the library to be used for the restore job. |
[scratchpool] |
[scratchpool]
<library_name>/<scratchpool_name> Example: [scratchpool] LN1/SN1 |
This is an optional parameter. Name of the scratchpool in the library to be used for the restore job. The drivepool and scratchpool parameters are applicable only if a tape library is used for the RMAN backup. The drivepool and scratchpool names can be given along with the library name followed by a backslash (/) or itself alone. |
Prior to running a restore operation from the CommCell Console, you can preview the corresponding RMAN script for the restore job. This is useful to determine whether the selected restore options will yield the desired result in the script. You can also manually copy and save the generated RMAN script to your computer and later execute the script from the command line.
|
In addition to previewing the RMAN script, you can also modify the script from the CommCell Console. This is useful when you want to include the RMAN commands that is not supported by the software.
|
[CvClientName] |
[CvClientName] <Client_Name> Example: [CvClientName] client_name |
Name of the client defined in the CommCell Console and the client name from where RMAN script runs. This parameter is optional. It is primarily used in a clustered environment. |
[CvInstanceName] |
[CvInstanceName] <Instance_Name> Example: [CvInstanceName] instance_name |
Name of the Calypso instance installed on the client from
where the RMAN script runs. This parameter is optional. In cases of multiple instances of the software, the first installed instance would be 'Instance001'. |
[CvOraSID] |
[CvOraSID] <oracle_sid> Example: [CvOraSID] DB1 |
Name of the Oracle System ID (SID). This parameter is used during multi
stream backups and also when the Oracle database name is different from
Oracle SID. It is also used for multistream restores to get single job
id. This parameter is optional. In case of a duplicate database restore, CvOraSID must be the destination SID name, otherwise in all cases it is source SID. |
[CvSrcClientName] |
[CvSrcClientName]
Source_client_name |
Name of the Source client defined in CommServe for which restore should look for backup pieces. It will be needed for cross-machine/duplicate restores to get correct backup piece of the required oracle instance when there are conflicting backup pieces between two oracle instances on different clients. |
Prior to running the RMAN scripts from the RMAN command line, do the following:
1. | Add the environmental variables for the client and instance on which the iDataAgent is installed. |
allocate channel ch1 type 'sbt_tape'
PARMS="<software install path>/Base/libobk.so,ENV=(CvClientName=clientname,CvInstanceName=instancename)" |
2. | On Unix clients, add the SBT LiBRARY path. |
For example,
allocate channel ch1 type 'sbt_tape' PARMS="SBT_LIBRARY=<software install path>/Base/libobk.so,ENV=(CvClientName=clientname,CvInstanceName=instancename)" The SBT_LIBRARY path for the various platforms are listed below:
|
3. |
Add the same block size value that was used for the corresponding backup
job. You can skip this step if the default block size was used for the backup. |
allocate channel ch1 type 'sbt_tape'
PARMS=" SBT_LIBRARY=<software install path>/Base/libobk.so, ENV=(CvClientName=clientname,CvInstanceName=instancename),BLKSIZE=32768"; |
4. | From the RMAN command prompt, connect to the target database. | rman target sys/sys@<databasename> |
5. | Execute the RMAN script. | @restore.txt |
The restore and recover processes are run as separate RMAN run blocks and hence when resumed, the job is restarted from the last failed RMAN run block.
During restores, if the primary copy of the database is not available, you can restore from a secondary copy using the RMAN command line.
1. | Include the environmental variable for copy precedence in the RMAN script. |
allocate channel ch1 type 'sbt_tape'
PARMS=" SBT_LIBRARY=<software install path>/Base/libobk.so, ENV=(CV_restCopyPrec=2,CvClientName=clientname,CvInstanceName=instancename),BLKSIZE=32768"; |
2. | From the RMAN command prompt, connect to the target database. | rman target sys/sys@<databasename> |
3. | Execute the RMAN script. | @restore.txt |
In order to restore using multple streams from RMAN interface, set the following parameters in the RMAN script.
1. | Set the number of automatic channels for a specific device type using the CONFIGURE DEVICE TYPE ... PARALLELISM command. |
CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2
BACKUP TYPE TO BACKUPSET;
In the above example, RMAN allocates two channels for the device type when using automatic channels. |
2. | Run the restore operation. Make sure to set the CvOraSID parameter to run the restore operation with a single job ID. |
run
{allocate channel ch1 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path>/Base64/libobk.so,ENV=(CvClientName=rdlab04,CvOraSID=DB1,CvInstanceName=Instance001)"; allocate channel ch2 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path>/Base64/libobk.so,ENV=(CvClientName=rdlab04,CvOraSID=DB1,CvInstanceName=Instance001)"; allocate channel ch3 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path>/Base64/libobk.so,ENV=(CvClientName=rdlab04,CvOraSID=DB1,CvInstanceName=Instance001)"; restore database ; recover database ; sql "alter database open"; } |
3. | If you are using the OEM application, include the RMAN settings in the Oracle Enterprise Manager. |
For Unix:
SBT_LIBRARY=<software_install_path>/Base|Base64/libobk.so,BLKSIZE=262144, ENV=(CvClientName=client_name,CvInstancename=Instance_name,CvOraSID=database_name) Windows: ENV=(CvClientName=client_name,CvInstanceName=Instance_name,CvOraSID=database_name),BLKSIZE=262144 |
If there are same backup piece names for two different oracle instances, while command line restore going on, you might see the following errors:
Include the environmental variable for the source Oracle instance name in the RMAN script.
allocate channel ch1 type 'sbt_tape'
PARMS=" SBT_LIBRARY=<software install path>/Base/libobk.so,
ENV=(CvClientName=clientname,CvInstanceName=instancename,,CvSrcOraSID=sourceoracleSID),BLKSIZE=32768";
Include the environmental variable for the source client name in the RMAN script.
allocate channel ch1 type 'sbt_tape'
PARMS=" SBT_LIBRARY=<software install path>/Base/libobk.so,
ENV=(CvClientName=clientname,CvInstanceName=instancename,CvSrcClientName=sourceclientname),BLKSIZE=32768";
Include the environmental variable for the source client name in the RMAN script.
allocate channel ch1 type 'sbt_tape'
PARMS=" SBT_LIBRARY=<software install path>/Base/libobk.so,
ENV=(CvClientName=clientname,CvInstanceName=instancename,CvSrcClientName=sourceclientname),BLKSIZE=32768";
In order to perform a restore operation, the database should be in the MOUNT mode. If the database is not in mounted state, you are prompted to switch the database to the mounted state and then perform the restore.
A static listener must be configured for database restores with the switch database mode when the Oracle database is in open mode. See When do we configure a static listener for additional information.
Use the following steps to automatically switch the database to mount mode prior to restore:
|
|
|
Sometimes, the database may not restart after switching the database during restore on Linux clients. To resolve this issue, see Restore - Troubleshooting.
After a restore operation, you need to open the database for recording further transactions.
Use the following steps to open the database:
|
|
|
By default, the database is automatically set to open and the logs are reset. Use the following steps to prevent resetting the logs:
|
|
|
When you perform a point-in-time recovery of an Oracle database with RESETLOGS, a new incarnation of the database is created. All archive log files generated after resetting the logs will be associated to the new incarnation. However, in order to perform a point-in-time recovery from a backup of a previous incarnation, you need to reset the current incarnation to the previous incarnation value. Use the following steps to set the incarnation value:
|
|
|
By default, the database is not reset. After resetting the logs to open state, you can reset the database. Use the following steps to reset the database after a restore:
|
|
|
During restore operations, RMAN automatically looks for another copy of the file under the following circumstances:
If it is not available in the other copy, RMAN will use older versions of the file, if available. When multiple channels are available for the same device type, RMAN will automatically retry on another channel. RMAN continuously searches all prior backups until it has exhausted all possibilities. This process will delay the restore jobs.
Use the following steps to disable the failovers during restore and prevent job delays:
|
|
|
|
|
|
By default, a specified post process command is executed only on successful completion of the restore operation.
Perform a restore operation even if the restore operation did not complete successfully. This may be useful to bring a database online or release a snapshot. Use the following steps to run a post process:
|
|
|
If you perform a validating restore job, the RMAN will stimulate a restore job and verifies whether the backup copies of data and logs required for the restore are intact and usable.
Use the following steps to validate a restore job:
|
|
|
The Database Identifier (DBID) is an internal, uniquely generated number that will distinguish the target database from the rest of the databases that have the same name in the recovery catalog. Oracle creates this number automatically when you create the database. The DBID is set while restoring the control file to differentiate the database for which the control file is restored.
Use the following steps to set the DBID and differentiate the database:
|
|
|
Each Oracle database has a redo log. This redo log records all changes made in datafiles. When you run your database in NOARCHIVELOG mode, you disable the archiving of the redo log.
By default, the No Redo Log is disabled. Hence, While restoring the database, RMAN will search for archived re-do logs after applying incremental backup data. Setting No Re-do Logs will enable the RMAN to suppress the archived re-do logs so that only data from incremental backups is restored. Enable No Re-do logs when you perform a point-in-time restore of a database that was backed up in NOARCHIVELOG mode.
Use the following steps to enable No Re-do Logs and perform a restore operation:
|
|
|
You can perform a restore operation faster when you set a maximum number of concurrent open datafiles for RMAN to read simultaneously. Use the following steps to enhance your restore operation:
|
|
|
Follow the steps given below to schedule a restore job:
|
|
|
|
|
|
The restore job will execute as per the schedule. |
Once you initiate the restore operation, a restore job is generated in the Job Controller. Jobs can be managed in a number of ways. The following sections provide information on the different job management options available:
Jobs that fail to complete successfully are automatically restarted based on the job restartability configuration set in the Control Panel. Keep in mind that changes made to this configuration will affect all jobs in the entire CommCell.
To Configure the job restartability for a specific job, you can modify the retry settings for the job. This will override the setting in the Control Panel. It is also possible to override the default CommServe configuration for individual jobs by configuring retry settings when initiating the job. This configuration, however, will apply only to the specific job.
Restore jobs for this Agent are resumed from the point-of-failure. |
|
The following controls are available for running jobs in the Job Controller window:
Suspend |
Temporarily stops a job. A suspended job is not terminated; it can be restarted at a later time. |
Resume |
Resumes a job and returns the status to Waiting, Pending, Queued, or Running. The status depends on the availability of resources, the state of the Operation Windows, or the Activity Control setting |
Kill |
Terminates a job. |
If a restore job fails to complete successfully, you can resubmit the job without the need to reconfigure the original job's restore options using the Resubmit Job feature. When a job is resubmitted, all the original options, restore destinations, and other settings configured for the job remain in tact.
Several additional options are available to further refine your restore operations. The following table describes these options, as well as the steps to implement them.
Be sure to read the overview material referenced for each feature prior to using them.
Option | Description | Related Topics |
Use hardware revert capability if available |
This option allow you to revert the data to the time when the snapshot was
created. Selecting this option brings back the entire LUN to the point when the
snapshot was created, overwriting all modifications to the data since the
snapshot creation. This option is only available if the storage array used for SnapProtect Backup supports the revert operation.
|
|
Startup Options |
The Startup Options are used by the Job Manager to set priority for resource allocation. This is useful to give higher priority to certain jobs. You can set the priority as follows:
|
Refer to Job Priority and Priority Precedence. |
Copy Precedence |
By default, the system retrieves data from the storage policy copy with
the lowest copy precedence. If the data was pruned from the primary
copy, the system automatically retrieves data from the other copies of
the storage policy in the lowest copy precedence to highest copy
precedence order. Once the data is found, it is retrieved, and no
further copies are checked. You can retrieve data from a specific storage policy copy (Synchronous Copy or Selective Copy). If data does not exist in the specified copy, the data retrieve operation fails even if the data exists in another copy of the same storage policy. Follow the steps given below to retrieve the data from a a specific storage policy copy:
|
Refer to Recovering Data From Copies. |
Data Path Options |
The data recovery operations use a default Library, MediaAgent, Drive Pool, and Drive as the Data Path. You can use this option to change the data path if the default data path is not available. Follow the steps given below to change the default data path:
|
Refer to Change Data Path. |
Encryption |
If the client's data is encrypted with a pass phrase, you must enter the pass-phrase to start the data recovery operation. Follow the steps given below to enter the pass-phrase:
|
Refer to Data Encryption. |
Alerts |
This option enables users or user groups to get automatic notification on the status of the data recovery job. Follow the steps given below to set up the criteria to raise notifications/alerts:
|
Refer to Alert. |
CommCell Readiness Report |
The CommCell Readiness Report provides you with vital information, such as
connectivity and readiness of the Client, MediaAgent and CommServe. It is useful
to run this report before performing the data protection or recovery job. Follow the steps
given below to generate the report:
|
Refer to CommCell Readiness Report. |
Restore Job Summary Report |
The Restore Job Summary Report provides you with information about all the data recovery jobs that are run in last 24 hours for a specific client and agent. You can get information such as failure reason, failed objects, job options etc. It is useful to run this report after performing the restore. Follow the steps given below to generate the report:
|
Refer to Restore Job Summary Report. |