Full backups provide the most comprehensive protection of data.
Backups for any client start with a full backup. The full backup becomes a baseline to which subsequent backup types are applied. For example, a full backup must be performed before an archive log backup can be initiated.
You can perform a full backup of an online or offline database. If the database is in NOARCHIVELOG mode, you should perform offline backup only.
Use the following steps to run a full backup:
In a cumulative level n backup, all the data changes since the most recent backup at level n-1 or lower are backed up.
For example, in a cumulative level 2 backup, data changes since the most recent level 1 backup are backed up. If no level 1 backup is available, data changes since the base level 0 backup are backed up.
Cumulative incremental backups reduce restore times because you need one incremental backup from any particular level. However, cumulative backups require more space and time because they duplicate the work done by previous backups at the same level.
By default, the incremental level for cumulative backups is 1.
Follow the steps below to perform a cumulative incremental backup:
An archive log backup captures the archive redo logs generated during database transactions.
Archive log backups are useful when you want to recover database transactions that have been lost due to an operating system or disk failure. You can apply these archive logs to an online backup in order to recover a database.
By default full backups include both data and archive logs. However, you can also perform separate archive log backups.
In order to perform a backup of the archive logs:
Use the following steps to backup all archive logs. Note that this is the default option:
Use the following steps to backup archive logs older than a specified number of days.
Use the following steps to backup archive logs not older than a specified number of days.
Use the following steps to backup archive logs between a specified time:
Log Sequence Number uniquely identifies an archive log. For example, if you create a database with two online log files, then the first file is assigned log sequence number 1. When the first file fills Oracle switches to the second file and assigns a log sequence number of 2; when it switches back to the first file, it assigns log sequence number 3, and so forth.
Use the following steps to backup archive logs within a specific range of log sequence numbers:
System Change Number (SCN) is a stamp that defines a committed version of a database at a point in time. Oracle assigns every committed transaction a unique SCN. For example, SCNs of two successive transactions committed could be 576601 and 576799.
Use the following steps to backup archive logs within a specific range of system change numbers:
Use the following steps to backup archive log files whose name match a specific naming pattern. Note that if you do not specify any pattern, all the logs from the specified destination will be backed up.
Use the following steps to backup archive logs from a specific path or location. Note that the path or location specified at the backup level will override the archive log location defined at the subclient level.
Use the following steps to backup archive logs that have failed to backup a specified number of times earlier:
Always ensure that the archive logs are backed up before they are deleted to prevent data loss. |
However, you can also choose to delete the archive logs for a specific backup job. Moreover, you can also specify additional criteria to delete the archive logs.
The subclients need to be configured prior to running control file backups; see Enable/ Disable Control File Backups for a Specific Subclient for step-by-step instructions.
Use the following steps to backup the control file:
Oracle 12c supports container and pluggable databases. Calypso supports the backup of container and pluggable databases. You can backup the entire container database or one or more pluggable databases.
Container databases can be backed up by creating an instance for the container database. Single and multiple pluggable databases can be separately backed up through custom RMAN scripts.
When you backup a container database, all pluggable databases that are part of the container database are also backed up.
1. | Create and
customize
an RMAN script file on the client computer, where the last line in the
script specifies the pluggable database to back up. The line has
the following format, with "pluggable_database_name" specifying the
pluggable database to back up. pluggable database pluggable_database_name; |
Example: RMAN script backing up the pluggable database
"SINGLE_PDB". run { Click here to see the RMAN log output for this example. |
2 | Execute the RMAN script. | See Running RMAN Scripts from Third Party Command Line. |
1. | Create and
customize
an RMAN script file on the client computer, where the last line in the
script specifies the pluggable databases to back up. The line has
the following format, with "pluggable_database_name1" through "pluggable_databaseN. Each database must be
separated by a ",". pluggable database pluggable_database_name1, ..pluggable_database_nameN; |
Example: RMAN script backing up the pluggable databases
"PLUG_DB1" and "PLUG_DB2". run { Click here to see the RMAN log output for this example. |
2 | Execute the RMAN script. | See Running RMAN Scripts from Third Party Command Line. |
The content for the backup operation during On Demand backup is provided in an RMAN script and executed from the command line interface. You need to create an On Demand instance to perform on demand backup operations. Refer Creating an On Demand Instance for step by step instructions.
1. | Create an RMAN script file on the client computer. | Example: RMAN script file for archive log backup run { allocate channel ch1 type 'sbt_tape' PARMS="BLKSIZE=262144"; sql 'alter system archive log current'; backup filesperset 4 (archivelog all); } exit |
2. | Create the parameter file on the client with the path to
the specified RMAN script file. See RMAN Parameters for a list of mandatory and optional RMAN parameters. |
Example: Parameter file argfile1.txt with path to
RMAN script file, backuplogs.txt,
specified: [instancescripts] ora11gv1,D:\backuplogs.txt [datatype] LOG [sp] SP1 [streamcount] 2 |
3. | From the command prompt, login to the CommServe using the qlogin command. | Example: To log on to CommServe server1 with user
name user1: D:\>qlogin -cs server1 -u user1 Password: |
4. | Run the backup operation using qoperation backup. | Example: To run a full backup on client client1
using the parameter file argfile1.txt: D:\>qoperation backup -c client1 -a Q_ORACLE -af /argfile1.txt -t Q_FULL |
Parameter | Usage | Description |
[instancescripts] |
[instancescripts]
<instance name>,<file name> Example: [instancescripts] ora11gv1,D:\backuplogs.txt |
Name of the instance to be backed up, and the name of the file that contains the RMAN backup script. |
[datatype] |
[datatype]
DATA | LOG Example: [datatype] LOG |
Mark the associated backup archive files as either DATA or LOG. |
[sp] |
[sp]
<StoragePolicyName> Example: [sp] SP1 |
Name of the Storage Policy to be used for the RMAN backup job. |
[streamcount] |
[streamcount]
<number> Example: [streamcount] 2 |
Number of streams to reserve for the RMAN backup job. |
[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 backup output file will be saved and the name of the output file. By default, an output file backup.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_Bkp_RmanLogFile registry key. |
[options]
|
|
These are optional parameters.
|
[mediaagent] |
[mediaagent]
<mediaagentname> Example: [mediaagent] MA1 |
This is an optional parameter. Name of the MediaAgent to be used for the backup job. |
[library] |
[library]
<libraryname> Example: [library] LN1 |
This is an optional parameter. Name of the library to be used for the backup 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 backup 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 backup 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. |
[jobdescription] |
[jobdescription]
<jobdescription> Example: [jobdescription] weekly_data_bkp |
This is an optional parameter. Job description for the backup job. |
Command line backups enable you to perform backup operation on multiple clients simultaneously. In order to run the backups from command line, you need an input xml file which contains the parameters for configuring the backup options. This input xml file can be obtained from 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 backup_template.xml -backupLevel FULL -subclientName xxxxx -clientName xxxxx -instanceName xxxxx
qlist job –j JOBID
qlogout [-cs commserver] [-all] [-tf tokenfile] [-tk token] [-h]
Performing a Full Backup |
qoperation execute -af backup_template.xml -backupLevel FULL -subclientName subclient1 -clientName client1 -instanceName instance1 |
Performing an Incremental Backup |
qoperation execute -af backup_template.xml -backupLevel INCREMENTAL -subclientName subclient1 -clientName client1 -instanceName instance1 |
In addition to the parameters provided in the template xml file, if you want to include additional options for the backup, you can do so by selecting the required options from the CommCell Console and generate the command line xml script for the backup.
Follow the steps given below to generate a script which you can use to perform a backup from the command line interface:
You can submit RMAN scripts from the Command Line Interface using QCommands. The RMAN scripts are submitted through argument files.
[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. |
When you submit RMAN scripts using QCommands:
1. | Create an argument file on the client computer. | Example: Argument file for full backup argfile.txt [client] machine1_cn [dataagent] Q_ORACLE [instance] orcl [subclient] default [backuptype] Q_FULL |
2. | From the command prompt, login to the CommServe using the qlogin command. | Example: To log on to CommServe server1 with user
name user1: qlogin -cs server1 -u user1 Password: |
3. | Run the backup operation using qoperation backup. | Example: To run a full backup on client using
argument file argfile.txt: D:\>qoperation backup -af D:\argfile.txt |
Use the following steps to run backups from the third-party command line:
1. | Create an RMAN script file on the client computer. | Example: backup.txt |
2. | From the RMAN command prompt on the client computer, add the environmental variables for the client and instance on which the iDataAgent is installed. | Example: allocate channel ch1 type 'sbt_tape' PARMS="ENV=(CvClientName=<client_name>, CvInstanceName=<instance_name>)" |
On Unix clients, add the SBT_LIBRARY path. | Example:
allocate channel ch1 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path>/Base/libobk.so, ENV=(CvClientName=<client_name>, CvInstanceName=<instance_name>)"
The SBT_LIBRARY path for the various platforms are listed below:
|
|
3. | Add the RMAN script for backup to the file backup.txt. | Example: RMAN script file backup.txt
run { allocate channel ch1 type 'sbt_tape' PARMS="BLKSIZE=262144, SBT_LIBRARY=/opt/calypso/Base/libobk.so, ENV=(CvClientName=<client_name>,CvInstanceName=<instance_name>)"; backup database; release channel ch1; } |
4. | Connect to the target database. | rman target sys/sys@<databasename> |
5. | Execute the RMAN script. | @backup.txt |
Oracle third party command line operations running on multiple streams will share the same Job ID in the Job Manager. If all the streams return failure, then the job is marked as failed. However, if one of the streams fail, it is submitted to the other stream for completion.
Use the following steps to run multi stream backups from the third party command line:
1. | From the RMAN command prompt, set the number of automatic
channels for a specific device type. Note that to utilize the PARALLELISM option, set the initial parameter in pfile or spfile. Eg., BACKUP_TAPE_IO_SLAVES=TRUE |
In the below example, RMAN allocates two channels for the
device type when using automatic channels. CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO BACKUPSET; |
2. | If you are using the OEM application with multiple channels, include the RMAN settings in the Oracle Enterprise Manager. | Example:
Unix: SBT_LIBRARY=<software_install_path> /Base64/libobk.so, BLKSIZE=262144,ENV=(CvClientName=<client_name>, CvInstanceName=<instance_name>, CvOraSID=<oracle_sid>
Windows: ENV=(CvClientName=<client_name>, CvInstanceName=<instance_name>, CvOraSID=<oracle_sid>),BLKSIZE=262144 |
3. | Create RMAN script file to run the backup operation with a single job ID,
and save it in the desired <location_path>/<file_name>. For example,
D:\backup1.txt. When creating the RMAN script, the CvClientName and CvOraSID parameters can be used optionally for backup jobs. If you use both the RMAN PARALLELISM configure parameter and set multiple streams from RMAN script, the backup job will utilize double the number of streams. For example, if PARALLELISM is set to 2 and 2 streams are set from RMAN script, the backup job will utilize 4 streams. |
Example: Content in RMAN script file backup1.txt run {allocate channel ch1 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path> /Base64/libobk.so, ENV=(CvInstanceName=<instance_name>, CvClientName=<client_name>, CvOraSID=<oracle_sid>)";
allocate channel ch2 type 'sbt_tape' PARMS="SBT_LIBRARY=<software_install_path> /Base64/libobk.so, ENV=(CvInstanceName=<instance_name>, CvClientName=<client_name>, CvOraSID=<oracle_sid>)";
setlimit channel ch1 maxopenfiles 1; setlimit channel ch2 maxopenfiles 1; backup incremental level = 0 filesperset = 32 database include current controlfile; sql "alter system archive log current"; backup filesperset = 1 (archivelog all delete input); } |
4. | Connect to the target database. | rman target sys/sys@<databasename> |
5. | Navigate to the saved location and execute the RMAN script. | @<file_path>backup1.txt |
Prior to running a backup operation from the CommCell Console, you can preview the corresponding RMAN script for the backup job. This is useful to determine whether the selected backup 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 are not supported by the software. Use the custom rman scripts to run the saved stored scripts. For example:
To run a backup stored script:
a. create stored script
[oracle@brahmani64 ~]$ rman target sys/sys@netapp catalog snap/snap@test
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Oct 18 11:06:36 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: NETAPP (DBID=3312111657)
connected to recovery catalog database
RMAN> create global script backup_script
2> {
3> backup database;
4> }
created global script backup_script
RMAN>
You should include recovery catalog to successfully run customized rman scripts. See Using Recovery Catalog for Backups for more information.
Use the following steps to run the custom rman scripts from CommCell Console:
Follow the steps given below to schedule a backup:
1.. |
|
![]() |
By default, browse query will automatically run on the database to collect datafile names when you perform a backup. This SQL query may hang or hamper the backup performance. Use the following steps to skip database browsing before performing a backup:
|
![]() |
Backup performance can also be enhanced by setting additional configurations at the subclient level. See Enhancing Backup Performance for more details.
Use the following steps to set the RMAN disk ratio:Use the following steps to validate the backup jobs of a subclient:
Use the following steps to disable the RMAN warnings:
|
![]() |
Note that if this option is set in both the client and the CommServe, the client side value will override the value set in the CommServe.
|
![]() |
|
![]() |
Note that if this option is set in both the client and the CommServe, the client side value will override the value set in the CommServe.
|
![]() |
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.
Backup 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. |
The following table describes the available additional options to further refine your backup operations:
Option | Description | Related topics |
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. |
Alerts |
This option enables users or user groups to get automatic notification on the status of the data protection job. Follow the steps given below to set up the criteria to raise notifications/alerts:
|
Refer to Alerts. |
Vault Tracker |
This feature provides the facility to manage media that is removed from a library and stored in offsite locations. Depending on your VaultTracker setup, select the required options. Use the following steps to access and select the VaultTracker options.
|
Refer to VaultTracker or VaultTracker Enterprise. |
Extended Data Retention |
This option allows you to extend the expiration date of a specific job. This will override the default retention set at the corresponding storage policy copy. Follow the steps given below to extend the expiration date:
|
Refer to Extended Retention Rules. |
Allow Other Schedules to Use Media Set |
The Allow Other Schedules to use Media Set option allows jobs that are part of the schedule or schedule policy and using the specific storage policy to start a new media. It also prevents other jobs from writing to the same set of media.
|
Refer to Creating an Exportable Media Set. |
Mark Media Full |
This option marks the media as full, two minutes after the successful completion of the data protection job. This option prevents another job from writing to this media. Follow the steps given below:
|
Refer to Start New Media. |
Start New Media |
The Start New Media option enables you to start the data protection operation on a new media. This feature provides control over where the data physically resides. Use the following steps to start the data protection operation on a new media:
|
Refer to Start New Media. |
Data Path Options |
Data Protection 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 Change Data Path. |
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. |
Backup Job Summary Report |
The Backup Job Summary Report provides you with information about all the
backup jobs that are run in last 24 hrs for a specific subclient. You can get
information such as status, time, data size etc. for each backup job. It is useful
to run this report after performing the backup. Follow the steps
given below to generate the report:
|
Refer to Backup Job Summary Report. |