Offline backups can be performed when the database is in offline or online mode. If the database is online, it shuts down the database, performs the backup and then brings up the database back.
Once you perform a SnapProtect backup, perform a log backup. You will need to create a separate subclient for log backups. By default, the system will use data storage policy for SnapProtect backups and backup copy. If you create a log specific subclient, the log specific storage policy is used for SnapProtect backups and backup copies.
Use the following steps to configure log backups.
You can customize the pruning of archive logs after the backup using RMAN Scripts. If applicable, you will also need to specify the connect target string and connect string for a recover catalog for a full RMAN script.
RMAN will not know which archive logs have been backed up for file system movement to tape. Hence, we need to prune all the backed up archive logs. Use the following command to prune the logs for file system movement to tape:
connect target sys/****@oracledb
connect catalog catuser/****@catalog
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-XX’
rman cmdfile</path/to/rman.script>
Example:
connect target sys/syspw@oracledb
connect catalog catuser/syspw@catalog
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-2’
rman cmdfile</path/to/rman.script>
If you run the command in the above example, RMAN will remove all archive logs on the disk that are older than 2 days.
You can use the same command used for file system movement to tape to prune all archive logs. In addition, you can also use the following command to delete the archive logs that have been backed up multiple times, if you are saving multiple copies of archive logs to optimize your database recovery:
connect target sys/****@oracledb
connect catalog catuser/****@catalog
DELETE NOPROMPT ARCHIVELOG ALL BACKED UP XX TIMES TO DEVICE TYPE sbt;
rman cmdfile</path/to/rman.script>
Example:
connect target sys/****@oracledb
connect catalog catuser/****@catalog
DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
rman cmdfile</path/to/rman.script>
If you run the command in the above example, RMAN will remove all archive logs that have been backed up at least 2 times to device type ‘sbt’.
Selective Online Full backup is a full backup taken when Oracle database is online, and the backup data is copied to a selective copy (during an auxiliary copy operation) from which it can be restored.
When a table backup is performed, all database tables are gathered in order to present the backup data in a table view during a browse operation.
Use the following steps to configure table backups:
If Oracle home of ASM instance and RDBMS instance are different, then make sure to separately configure ASM instance on the CommCell Console in additions to RDBMS instance.
Make sure that the kfed utility resides under <Oracle ASM Home>/bin location. If the kfed utility do not exist, then build the kfed utility as shown in the following example:
Ensure that the ASM disk string is not empty. Use the following steps to configure the ASM instance:
If the ASM disks are from persistent snap engine, then you need to disable the snap integrity. Refer Disabling Verification of Datafiles during SnapProtect Backup for more information.
Use the following steps to schedule a backup. When scheduling backups, ensure that you schedule the log backups soon after a SnapProtect backup.
The following steps are performed automatically when you perform a SnapProtect backup:
Cataloging is performed to verify whether all the datafiles are properly captured during a SnapProtect backup. RMAN catalog datafilecopy will check the datafile header and verify its authenticity before cataloging it.
Use the following steps to disable the cataloging operation:
|
![]() |
qoperation execute -af update_sc.xml -clientName <clientname> -instanceName <oraclesid> -subclientName <subclientname> -storagePolicyName <storagepolicyname> -isSnapBackupEnabled true
qoperation execute -af update_sc.xml -clientName <clientname> -instanceName <oraclesid> -subclientName <subclientname> -storagePolicyName <storagepolicyname> -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine>
qoperation execute -af update_sc.xml -clientName <clientname> -instanceName <oraclesid> -subclientName <subclientname> -storagePolicyName <storagepolicyname> -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine> -snapToTapeProxyToUse/clientName <proxy client>
If you select RMAN for backup copy, you should install the Oracle iDataAgent and the oracle instance configured in CommCell browser should be identical to the instance in the source computer.
qoperation execute -af update_sc.xml -clientName <clientname> -instanceName <oraclesid> -subclientName <subclientname> -storagePolicyName <storagepolicyname> -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine> -snapToTapeProxyToUse/clientName <proxy client> -isRMANEnableForTapeMovement true
You must perform a full backup job after enabling/disabling SnapProtect backup.
qoperation execute -af update_sc.xml -clientName <clientname> -instanceName <oraclesid> -subclientName <subclientname> -storagePolicyName <storagepolicyname> -isSnapBackupEnabled false
The following table displays all the parameters you can use with the commands mentioned in the above sections. To add a parameter to your command, use the following syntax: (A example is provided at the end of the table.)
qoperation execute -af <template XML file> -<parameter name> <value>
Parameter | Description of Parameter Values |
clientName | Name of the client computer, as displayed in the CommCell Browser |
instanceName | Name of the oracle instance |
subclientName | Name of the Subclient used for SnapProtect operations |
storagePolicyName | Name of the storage policy used for SnapProtect operations |
isSnapBackupEnabled (true/false) | To enable/disable a SnapProtect backup |
snapShotEngineName | To define the engine to be used for a SnapProtect backup |
snapToTapeProxyToUseSource (true/false) | To enable/disable using source if proxy is unreachable |
snapToTapeProxyToUse clientName="client_name" | To define proxy client to be used of backup copy operations. |
isRMANEnableForTapeMovement(true/false) | To enable/disable using RMAN for backup copy |
The following example shows how to add a parameter for a command:
Enabling SnapProtect Backup |
Enable SnapProtect backup for instance name under client brahmani64. ./qoperation execute -af update_sc.xml -clientName brahmani64 -instanceName dctmdb -subclientName command_test1 -storagePolicyName 9815 -isSnapBackupEnabled true |
Selecting Snap Engine |
Select a Snap engine for instance name dctmdb under client
brahmani64 and subclient name command_test1. ./qoperation execute -af update_sc.xml -clientName brahmani64 -instanceName dctmdb -subclientName command_test1 -storagePolicyName 9815 -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine> |
Selecting A Proxy Client For Movement To Tape |
Select a proxy client for brahmani64 for movement to tape. ./qoperation execute -af update_sc.xml -clientName brahmani64 -instanceName dctmdb -subclientName command_test1 -storagePolicyName 9815 -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine> -snapToTapeProxyToUse/clientName <proxy client> |
Selecting RMAN Backup Copy |
Select a Snap engine for instance name dctmdb under client
brahmani64 and subclient name
command_test1. ./qoperation execute -af update_sc.xml -clientName brahmani64 -instanceName dctmdb -subclientName command_test1 -storagePolicyName 9815 -isSnapBackupEnabled true -snapShotEngineName <Snapshot engine> -snapToTapeProxyToUse/clientName <proxy client> -isRMANEnableForTapeMovement true |
Disabling SnapProtect Backup |
Disable SnapProtect operation for instance name dctmdb under client
brahmani64. ./qoperation execute -af update_sc.xml -clientName brahmani64 -instanceName dctmdb -subclientName command_test1 -storagePolicyName 9815 -isSnapBackupEnabled false |
You can perform a SnapProtect backup for Oracle when the database is on a NFS Volume. However, you will require a root access in the storage device's NFS configuration to be able to read and write on the accessible Oracle files i.e., the host on which the NFS Volume is mounted.
You can also perform SnapProtect backups for Oracle if the database resides on a Direct NFS volume. SnapProtect backups supports volumes using the Oracle Direct NFS (dNFS) protocol.
File level reverts can also be performed when the database is on a NFS volume by using the sUSE_FILE_LEVEL_REVERT registry key. Do not perform the file level revert when the database resides on a NFS with regular LUNs.
Consider the following while performing a SnapProtect backup for data or databases that reside on a NFS Volume:
E.g., if the storage path of the storage device is /vol/Volume/Qtree, use /vol/Volume/Qtree as the export name and not an alias such as /ExportName.
E.g., use a short name for the server such as server1 or server2.
You can perform SnapProtect operations for a single node Oracle RAC setup. When configuring the Oracle RAC components for a SnapProtect backup, ensure the following:
You must select a physical client and a RAC instance under such physical client for scheduling SnapProtect operations. It is recommended to configure the RMAN catalog prior to performing a SnapProtect backup.
Use the following steps to configure a RAC instance for SnapProtect operations using a single node:
- In the Instance (ORACLE SID) box, type the RAC Instance name.
- In the ORACLE USER box, type the user account name for RAC Instance.
- In the ORACLE HOME box, type the Oracle home path for RAC instance. Alternatively, you can click Browse to select the location.
- Select the Storage Policy for the data of a default subclient from the list.
Example: sys/password1@racdb1
Make sure that the kfed utility resides under the following location:
<Oracle ASM Home>/bin
If the kfed utility do not exist, build the kfed utility as shown in the example:
cd <Oracle ASM Home>/rdbms/lib
make –f ins_rdbms.mk ikfed
You must configure an ASM instance since Oracle RAC SnapProtect operations support only ASM instances (In case of a first node, it is +ASM1). |
When you perform a SnapProtect backup for online databases, ensure you also backup the archive logs. The archive log destination should be shared among all RAC instances. If the log destination is not shared among all RAC instances, you need to separately schedule the archive log backups using a user-defined subclient.
When you backup archive logs, you can specify the location (archive log destinations) from where log backups should be performed. Oracle RAC database will be distributed across many physical clients. These physical clients may or may not share archive log destinations for all instances.
Use the following steps to configure backups for online databases if the archive log destination is shared among all RAC instances:
You can use RMAN for copying the data to the media in an Oracle RAC setup. When
the data is moved to
media, the RMAN backup
interface is used for block level backup operations. Also, these backup
operations are
recorded on the RMAN catalog.
RMAN is required in the case of Automatic Storage Management (ASM) Oracle Databases, since ASM data is not available on the file system. Prior to using RMAN for copying the data to the media, ensure the following:
If you plan to use RMAN for copying the data to the media on the proxy computer, copy the Oracle parameter file (pfile) from the client to the proxy computer's $ORACLE_HOME/dbs/ directory, and remove any parameter containing Oracle RAC related entries. For example:
Use the following steps to configure the RMAN backup copy for Oracle RAC setup: |
|
![]() |
The snapshots of the data created by the SnapProtect backup are also available for various other operations like list, mount, unmount, delete, or revert.
The browse operation provides the capability to see the snapshots created for
an agent, job, or a snapshot copy. The list of the snapshots displayed is corresponding
to the entity selected for the browse operation, for e.g., browsing the snapshots
for an agent will display all the snapshots created for the selected agent. You can
view volume or disk related information for the snapshots. Follow the steps given
below to browse snapshots.
You can also browse snapshots at the instance level of the Oracle Agent. |
![]() |
You can mount any available snapshot to access the data included in the snapshot. It is recommended that you select the option to protect a snapshot when it is mounted, as this will ensure that the changes made to the snapshot when it is mounted are not retained when you unmount the snapshot and the snapshot is usable for data protection operations. Follow the steps given below to mount snapshots:
|
![]() |
Follow the steps given below to unmount snapshots:
|
![]() |
Snapshots can either be deleted using job-based pruning or from the list of displayed snapshots when browsing snapshots. Data Aging can also be used to define the retention rules and pruning of snapshots. Follow the steps given below to delete snapshots:
|
|
![]() |
Review the following before performing a revert operation:
On Unix clusters, use pre/post scripts to freeze and unfreeze the cluster for revert operations. For example, on Red Hat Linux cluster, use the following command in the pre/post scripts:
clusvcadm -Z <group> to freeze the cluster
clusvcadm -U <group> to unfreeze the cluster
This is required because, during revert the application is shut down and corresponding volumes are unmounted. In that case, the cluster will automatically failover to another node thus preventing the revert operation.
|
|
|
![]() |
Snapshots may be deleted from the array due to factors like low disk space on the array, number of snapshots exceeds the threshold etc., and the jobs corresponding to these deleted snapshots can no longer be used for any data recovery or backup copy operations. You can use the nRunSnapRecon registry key to start snap reconciliation to check for missing snapshots once in every 24 hours and marks jobs corresponding to the missing snapshots as invalid.
When restoring data from a snapshot, note the following:
Snapshots are mounted on the destination client where the restore is performed. Hence, destination client should have access to the storage array/filer where snapshot was taken. If the destination client does not have access to storage device, then you should restore the data from snapshot using proxy computer. You can restore an oracle database on a ASM disk group using RMAN.
Use the following steps to restore data from a snapshot using RMAN scripts:
|
![]() |
|
![]() |
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:
|
![]() |
You can use the revert operation to bring the oracle database back to the point in time when the SnapProtect backup was taken. However, the log volume will not be reverted. Hence, you can use either the file system or RMAN to revert the logs after reverting the data volume.
|
![]() |
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 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:
Prerequisites |
|
|
|
Setting up the Source and Destination Hosts |
|
|
Example: SQL>create user <username> identified by <password> 2>temporary tablespace <temp_tablespace_name> 3>default tablespace <default_tablespace_name> 4>quota unlimited on <default_tablespace_name>; Statement processed. SQL>grant connect, resource, recovery_catalog_owner to <username>; Statement processed. |
|
|
|
|
|
Example using IMPORT CATALOG Command: RMAN>IMPORT CATALOG user1/user1@src; |
|
<service_name> = (DESCRIPTION = (ADDRESS = (PROTOCOL = <protocol>)(HOST = <host>) (PORT = <##>)) (CONNECT_DATA = (SID = <Recovery Catalog database>))) |
|
Example: For Unix: #export ORACLE_SID= <target database SID> #export ORACLE_HOME= <Oracle home directory>
For Windows: C:\set ORACLE_SID= <target database SID> C:\set ORACLE_HOME= <Oracle home directory> |
|
|
|
|
Restoring the Database |
|
|
![]() |
|
![]() |
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):
|
![]() |
|
![]() |
|
![]() |
Archive logs can be restored separately or along with the database. If there is a database failure and you need to recover the database to the recent state, you will be able to restore all the logs along with the database.
Use the following steps to restore all the archived logs (note that this is the default option):
|
![]() |
|
![]() |
Database tables can be restored from a SnapProtect backup using RMAN. In order to restore database tables, you need to perform a SnapProtect backup with table browse enabled.
Use the following steps to restore database tables:
|
![]() |
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:
|
![]() |
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.
|
![]() |
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.
Use the following steps to automatically switch the database to mount mode prior to restore:
|
![]() |
|
![]() |
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:
|
![]() |
|
![]() |
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:
|
![]() |
|
![]() |
When restoring from a SnapProtect and RMAN mixed environment, the data can be restored from a SnapProtect or RMAN backup jobs depending on the browse time and whether the database full backup is a SnapProtect or RMAN backup job.
Consider the following scenarios:
Scenario 1
The backup jobs are performed in the following sequence:
In this scenario, when you restore a control file, SP file from autobackup or backup piece, the restore is always performed from the full SnapProtect backup job.
Similarly, when restoring only the archive logs, the logs are restored from the SnapProtect backup job instead of the latest archive log backup.
Scenario 2
The backup jobs are performed in the following sequence:
In this scenario, the restores are performed from the latest backup job (SnapProtect or RMAN) depending on the specified time.
If the SnapProtect full backup job and RMAN full backup job were executed in parallel, by default, the SnapProtect full backup job is used for the restore operation.
In a SnapProtect and RMAN mixed environment, you can configure to restore certain database components, such as control file, SP file, or archive logs from RMAN backup jobs by creating the sSNAPRESTORE registry key on the CommServe using the following steps. Once the restore is complete, make sure to delete this key to enable restores from SnapProtect backups.
|
![]() |
In a mixed mode environment, you can restore and recover the database to a point in time using the following steps:
The following sections describe the additional modes of Backup Copy Operations:
By default, the system will use the File System for copying the data to the media. The system will scan the file, generate and read the collect file, extract the file list and copies the data on to the tape using MediaAgent's data mover.
In order to perform the file system snap to tape copy on a proxy computer, ensure that the MediaAgent and File System iDataAgent are installed on the proxy computer.
|
![]() |
You can also use RMAN for copying the data to the media. When data is moved from snap to media, the RMAN backup interface is used for block level backup operations. Also, these backup operations are recorded on the RMAN catalog. RMAN is required in the case of Automatic Storage Management (ASM) Oracle Databases, since ASM data is not available on the file system. You can also run RMAN restores/reports from these backups. Prior to using RMAN for copying the data to the media, ensure the following:
|
|
![]() |
Oracle RMAN incremental backup copy can be performed on a proxy
server.
Prior to performing the RMAN incremental backup copy, ensure the following:
|
|
![]() |
By default, during RMAN backup copy the data snaps are mounted in the same location as source on proxy MediaAgents. In case of ASM databases, the ASM Disk Groups are not renamed during RMAN backup copy. This is to facilitate incremental RMAN backup copy where the datafile paths need to be in the same path as source.
However, if you use the same proxy MediaAgent for multiple databases RMAN backup copy may fail if the file system mount points or ASM Disk Group names of different Oracle instances conflict with each other.
In such cases, use the following steps to make the data snaps to be mounted on a different path or in case of ASM databases, to rename the ASM Disk Groups uniquely:
|
![]() |
You can perform a restore from the backup copy by setting the appropriate copy precedence number. Use the following steps to restore the data from backup copy using the File System backup:
|
![]() |
Use the following steps to restore the data from backup copy using RMAN. Refer Advanced Restore - Oracle iDataAgent for regular restore operations.
|
![]() |
|
![]() |
During a SnapProtect backup, snapshots will be created for each LUN
associated with a database. Snapshots will be created even when multiple
database instances share one or more LUNs. In such a case, the shared
LUNs will be backed up multiple times - once as part of every instance
using the LUN. When you enable the optimization and group all instances
that share a set of LUNs into a single schedule policy, each shared LUN
will be backed up only once. This will reduce the number of snapshots on
the storage, thus saving time and storage resources. Since multiple databases use one set of snapshots for backup, you can revert all the LUNs and databases in a single revert job. Without this optimization, reverting one database may corrupt data files of another database that shares the LUN(s). |
![]() |
Follow the steps given below to configure multiple instances using a shared storage on a client:
|
|||
|
|||
|
![]() |
||
|
|||
|
![]() |
||
|
|||
|
![]() |
||
|
![]() |
For clone operations, perform the following in addition to the above configuration:
qoperation execscript -sn OraMultiDBCGSnapConfig -si <ClientComputerGroup> -si <hourly/snap schedule policy> -si <daily/clone schedule policy> -si <y/n>(FullScan)
Client Computer Group | Create one client group and add all the clients for which snap/clone jobs will be performed |
Hourly/snap schedule policy | Create hourly schedule policy which will be used to run snap jobs for every hour |
Daily/clone schedule policy | Create daily schedule policy which will be used to run clone jobs once for daily. |
FullScan (Y/N) | If the value is "n", then it is incremental scan and as part of incremental scan it will check only newly created/discovered instances. subclients will be created for them only. Otherwise it will check all the instances in that client group and create subclients if any instance do not have the required subclients. |
When you execute the script, the system will check all the instances in that client group and perform the following steps:
<instancename>_snap
<instancename>_clone
If you are using NoArchiveLog mode Database, disable Use RMAN Movement to Tape. |
If you want to exclude instances from creating subclients and associating them to shared schedule policy, update the instance description with exclude with cvsnap schedule. Then the above script will not create subclients for those instances. See Update instance description to change the instance description using command line.
Once you execute the script, assign the storage policy and proxy client to all the subclients using the CommCell Console or command line.
Example:
Executing configuration script:
[root@brahmani64 Base]# ./qoperation execscript -sn
OraMultiDBCGSnapConfig -si CVLT -si hourly -si daily -si n
QScript[OraMultiDBCGSnapConfig] CS[leonard64] DB[CommServ] Source[SQL File]
Qscript Output:
Changed database context to 'CommServ'.
Created snap subclients for:
Client [brahmani64] Instance [par1]
Client [brahmani64] Instance [par2]
OraMultiDBCGSnapConfig completed at Aug 8 2012 11:48PM. ErrorCode (0).
Qscript Execution Succeeded!
Download the update_subclient_template.xml file and save it on the computer from where the command will be executed.
Execute the following command from the <Software_Installation_Directory>/Base folder after substituting the parameters and attributes.
qoperation execute -af update_subclient_template.xml -clientName brahmani64 -instanceName par1 -subclientName par1_snap -storagePolicyName snapSP
Make sure that the proxy is configured correctly before assigning a proxy to a subclient.
Execute the following command from the <Software_Installation_Directory>/Base folder after substituting the parameters and attributes.
qoperation execute -af update_subclient_template.xml -clientName brahmani64 -instanceName par1 -subclientName par1_snap -storagePolicyName snapSP -snapToTapeProxyToUse/clientName dbcs
You must disable Use RMAN movement to tape for NOARCHIVELOG databases.
Execute the following command from the <Software_Installation_Directory>/Base folder after substituting the parameters and attributes.
qoperation execute -af update_subclient_template.xml -clientName brahmani64 -instanceName par1 -subclientName par1_snap -storagePolicyName snapSP -snapToTapeProxyToUse/clientName dbcs -isRMANEnableForTapeMovement false
Download the update_snapengine_template.xml file and save it on the computer from where the command will be executed.
Execute the following command from the <Software_Installation_Directory>/Base folder after substituting the parameters and attributes.
qoperation execute -af update_snapengine_template.xml -clientName brahmani64 -instanceName par1 -subclientName par1_snap -storagePolicyName snapSP – snapShotEngineName “EMC CLARiiON Snapview Snap”
Execute the following command to change the instance description after substituting the parameters and attributes:
[root@brahmani64 Base]#./qoperation execscript -sn SetOracleInstanceProperties.sql -si brahmani64 -si 'Q_ORACLE' -si par1 -si 'User Description' -si 'exclude from cvsnap schedule' -si 1
When you configure a proxy for RMAN backup copy, make sure to satisfy the following requirements:
A snap or clone operation is performed for all the instances at the same time in a shared LUN environment using the schedule policy created specifically for this purpose. You can perform a snap or clone operation immediately or at a scheduled time.
When you perform a SnapProtect backup or a clone operation, the system performs the following:
Use the following steps to perform a SnapProtect backup:
|
![]() |
|
![]() |
|
![]() |
|
![]() |
|
![]() |
Use the following steps to schedule a SnapProtect backup for all the instances in a shared LUN environment:
1. |
|
![]() |
2. | Click Add button. |
![]() |
3. |
|
![]() |
4. |
Select the appropriate scheduling options.
For example:
|
![]() |
5. |
Select the appropriate advanced schedule options. For example:
|
![]() |
6. |
|
You can restore each database or some of the datafiles/table spaces from one database on a client.
Use the following steps to restore a database:
|
![]() |
|
![]() |
|
![]() |
|
![]() |
If you perform a revert from a SnapProtect job from a schedule policy, it will revert all the databases which were snapped in that SnapProtect backup job to the same point-in-time. Ensure that you have performed a SnapProtect backup for all the databases which share the same LUNs.
Ensure that both the data and log volumes are reverted for successful revert operation. By default, the data volumes only are reverted. Perform the following to revert the log volumes also in addition to data volumes:
|
![]() |
Use the following steps to revert a SnapProtect job:
|
![]()
|
||
|
![]() |
Once a revert is completed, resync the catalog using RMAN to register the new incarnation.
Example:
[oracle@brahmani64 ~]$ export ORACLE_SID=par2
[oracle@brahmani64 ~]$ rman target / catalog snap/snap@test
Recovery Manager: Release 10.2.0.4.0 - Production on Fri Jul 13 10:04:19 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PAR2 (DBID=1259990815)
connected to recovery catalog database
RMAN> resync catalog;
starting full resync of recovery catalog
full resync complete
RMAN>
Once the SnapProtect jobs are completed, you can perform or schedule backup copy jobs. You can run parallel backup copy for all the SnapProtect jobs which are performed using a schedule policy in one operation. In case of parallel backup copy, mount all the snaps in the first backup copy job itself. The other jobs will use these mount points and backup their corresponding databases.
|
![]()
|
See Backup Copy Operations and Restoring Data from Backup Copy for more information on backup copy operations.
Supported Configurations:
The adjacent diagram summarizes the Volume Manager support for SnapProtect backup. |
![]() |
The following options do not apply to SnapProtect backup for Oracle iDataAgent:
Dialog Box | TABS/Options Not Applicable |
Advanced Backup Options dialog box |
|
Subclient Properties dialog box |
|
The following options do not apply to snap restore for Oracle iDataAgent:
Dialog Box | TABS/Options Not Applicable |
Oracle Restore Options dialog box |
|
Advanced Restore Options dialog box |
|
Several additional options are available to further refine your backup operations. The following table describes the additional options:
Option | Description | Related topics | ||
SCSI Reservation |
SCSI reservation can be enabled for SnapProtect backup
for all the agents. Use the registry key
nSCSIReserveForSnap
to enable SCSI reservation. Enabling SCSI Reservation prevents other applications
(SCSI3 compliant) from using the reserved SCSI Device (i.e. the mounted
snapshot).
|
For more information on registry keys, Registry keys | ||
Pre/Post Commands |
The Pre/Post commands for SnapProtect backup
can either be executed on the proxy or the source computer. You can use
the Pre/Post Process tab of the Subclient Properties dialog
box to select where you wish to execute the Pre/Post commands. SnapProtect
backup supports Pre/Post commands for the agents that support it.
|
For more information on using the Pre/Post commands, see Pre/Post Processes. | ||
View Snapshot Details |
You can view the details of a snapshot for an agent, job,
or a snapshot copy. When you right-click any of these entities, you will
be able to browse all the snapshots corresponding to the selected entity.
|
|||
Select a Job for Backup Copy |
You can select a specific job for creating backup copy.
Once selected, the Move Snap to Tape field for the specific job will be
changed to Picked (i.e., the next backup copy operation will move this job
to media).
|
|||
Disable a Job for Backup Copy |
You can prevent a job from being moved to media. You
can apply this option to those jobs that were previously selected for moving
to media. On selecting this option, the Move Snap to Tape field for the
specific job will be changed to Not Picked (i.e., the next backup copy operation
will not move this job to media).
|
|||
Offline Snap Copy Job Summary Report | Offline Snap Copy Job Summary Report provides job summary details of backup copy jobs for moving snapshots to media. | See Backup Copy Job Summary Report for more details |