Backup - Oracle

Topics | How To | Troubleshoot | Related Topics

Overview

Supported Backup Types

Oracle Backup Jobs

• Oracle Selective Online Full Backups
• Optional Configuration for Oracle Backups
• Backup Arguments
• Table Backup

Backup Considerations

Advanced Backup Options

Overview

Plan your backup jobs for this agent by reviewing the following information:

• For an overview of backup jobs, see Backup Data.
• For a list of supported data types for this agent, see Supported Data Types.
• For information on subclients, see Subclients
  • For information on configuring subclients for this agent, see Subclients - Oracle.
• For information on running backups from the RMAN command line, see Third-Party Command Line Operations.

Supported Backup Types

This agent supports the following backup types:

• Full Backups
• Oracle Selective Online Full Backups
• Incremental Backups - The Oracle iDataAgent supports Levels 1 to 4 backups. For more information on incremental backups, refer to incremental backups in the Oracle Backup and Recovery Guide from Oracle Corporation. (The Oracle Incremental backups work as described in Differential backups. See Differential Backups for information on Oracle Incremental Backup.)
• Archive Log Backups

For Oracle On Demand backup jobs, in cases where multiple instances are backed up that are not all in the same mode, Job Manager will report the backup type as either Full (when the first instance in the backup script is in OPEN mode) or as Offline Full (when the first instance in the backup script is in MOUNTED mode).

Oracle Backup Jobs

This agent has the following unique functionality.

• Oracle Selective Online Full Backups
• Optional Configuration for Oracle Backups
• Backup Arguments
• Table Backup

Oracle Selective Online Full Backups

This is a special type of backup where a full backup is taken of the Oracle database while it is online, and the backup data can be copied to a selective copy (during an auxiliary copy operation) from which it can be restored.

The advantage of this type of backup is that both data and logs use the same storage policy, which means that they reside together on the same media, and are completely self-contained for restore and long term archiving purposes. This is especially useful in disaster recovery situations by alleviating the need to locate different offsite media from various jobs to gather the necessary data and logs to recover the database. Also, the data aging rules for selective online full backups are different from regular full backups, as both data and logs are aged together under the same storage policy.

There are certain rules that pertain to this type of backup that you should keep in mind:

• A selective online full backup job will wait for other Oracle backup jobs currently running on the same instance to complete, before it begins.
• For this type of backup, both data and archive logs will use the same storage policy as defined for data in the subclient, and will ignore the storage policy setting for archive logs (which is defined at the instance level).

• During selective online full backups, if the data streams (defined at the subclient level) is less than the archive log streams (defined at the instance level), then both the data phase and the archive log phase will use the same number of streams defined for the data in the subclient, and will ignore the number of streams set for the archive logs.

• While the data backup phase of a selective online full backup is running, the only other Oracle backup jobs that are allowed to run on the same instance are archive log backups. During the log backup phase of a selective online full backup, no other Oracle backups are allowed to run (neither logs nor data) on the same instance.
• If other Oracle archive log backup jobs are run at the same time as the selective online full backup, they will be forced to use the same storage policy used by the selective online full backup during the time-frame in which the selective online full backup job is running, and will be included in the same auxiliary copy operation. Refer to Oracle and Oracle RAC for more information on special data aging rules for selective online full backups.

Optional Configuration for Oracle Backups

Depending upon how your Oracle server and databases are set up, you may need to perform the following addition configuration.

Allocate Command Syntax for Oracle Command Line Backups on a Unix Cluster

In order to perform Oracle Command Line backups on a Unix cluster, you need to use the following syntax for the allocate command within the RMAN script:

allocate channel ChannelName type 'sbt_tape' PARMS="ENV=(CVOraVMName=VirtualMachineName)";

where ChannelName can be chN (N is a stream number: 1, 2, ...) and VirtualMachineName should be the name of the virtual machine.

Configuring Autobackup of Control Files

The control file contains metadata about the physical structure of the database including the location of all files, the current database state and system change number (SCN), as well as information about backups performed in RMAN. Oracle 9.2 and 10g provide the capability to configure autobackup of control files in RMAN so that they are automatically backed up along with the server parameter file during backup operations. The purpose of the control file autobackup is to provide a way to restore the backup repository contained in the control file when the control file is lost and the recovery catalog is either lost or was never used. You do not need a recovery catalog or target control file to restore the control file from autobackup. If you don’t use the catalog database for Oracle backups, and the entire database and control file are lost, then a restore of the entire database with control files will fail unless you have enabled autobackup of control files in RMAN.

See Configure Autobackup of Control Files for step-by-step instructions.

Configuring the Lights Out Script to Shut Down the Database for Offline Backups

In order to perform offline backups of the Oracle database, all users must be logged out of the database and it must be completely shut down. Certain options are available in the Subclient Properties (Backup Arguments) tab that allow you to automate the graceful shutdown of the Oracle database to perform offline backups. A brief description of these options, and their role in the shutdown sequence are provided below.

1. For Oracle on Unix, a warning message is issued to the physical node to notify users that the database will be shut down in a specified number of minutes and request that they log out of the database. This message is issued when the Warning option is enabled. Note that the Warning option is not supported for Oracle on Windows platforms.

2. For Oracle on Unix, after the warning message has been issued to the physical node, the lights out process will wait for the period of time specified in the Delay Time (min) option while users log out, before an attempt is made to shut down the database. After waiting the specified Delay Time, the SHUTDOWN IMMEDIATE statement is issued to the server.

3. The status of the database will be then checked to determine whether it is shutdown. If it is not shutdown, the system will retry issuing the SHUTDOWN IMMEDIATE statement, based on the following sequence of settings:
   1. Sleep Time (sec) - The lights out process will wait (i.e., sleep) for the specified number of seconds before retrying the SHUTDOWN IMMEDIATE statement and checking the status again. Because the goal is to shut down the database as quickly as possible, the Sleep Time in seconds is tried first, and must exhaust all the number of tries in the Tries Number setting located below the Sleep Time (sec) option, before switching over to the Sleep Time (min) option.

   2. Sleep Time (min) - If the number of tries limit has been reached for the Sleep Time (sec) option and the database has not been shut down yet, the lights out process will then begin waiting for the number of minutes specified in the Sleep Time (min) option before retrying the SHUTDOWN IMMEDIATE statement and rechecking the status again. The reasoning behind this approach is that once it becomes apparent to the system that it can't shut down the database quickly, it probably means that someone must be still logged in to the database in order to complete their work, and the system will retry at less frequent intervals, in this case minutes not seconds, in order to give the user time to complete and save the work. The system will keep retrying to shut down the database until it exhausts the number of tries in the Tries Number setting located below the Sleep Time (min) option. If the database is successfully shutdown, the backup will begin, otherwise the sequence continues to the next step.

4. Once the Tries Number limit is reached for the Sleep Time (min) option, then a SHUTDOWN ABORT statement will be issued to the server. If the SHUTDOWN IMMEDIATE statement has already completed within the specified time, this has no effect. Otherwise the SHUTDOWN ABORT overrides the SHUTDOWN IMMEDIATE statement and shuts down the database.

See Configure the Lights Out Script to Shut Down the Database for Offline Backups for step-by-step instructions.

Configuring the Oracle Tag for Backups

You can configure the Oracle Tag for backups on a subclient to uniquely identify a particular backup copy. The Oracle Tag specified for a backup can be used during a restore operation to tell the system which particular backup to restore the data from. Use of the Oracle Tag backup argument provides an alternative to point-in-time restores.

See Configure Backup Arguments for step-by-step instructions.

Backup Arguments

Some database iDataAgents run backups using a system-generated script that is run behind the scenes from a command line. The CommCell Console serves as a front-end user interface for specifying various backup arguments and parameters that are passed to the backup script that is run. Depending on your agent, you can specify, for example, the application-specific Backup Level, whether the backups will be online or offline, as well as buffer and bundle sizes, among other settings. Although the backup arguments/parameters vary among iDataAgents, they all function in a similar manner. These arguments are set at the subclient level from the respective iDataAgent's Subclient Properties dialog box tab.

For step-by-step instructions, see Configure Backup Arguments.

Table Backup

You can restore and recover individual database tables from non-system tablespaces to the same database or to another database. In order to restore individual Oracle or Oracle RAC database tables, you need to select the Enable Table Browse option in the Subclient Properties dialog box for the subclient prior to a backup. Note that this option can be enabled on only one subclient. Also, ensure that this option is not enabled on the LOGS-only subclient. When this option is enabled, information such as Oracle tablespace, user ID and table name mappings are stored in the CommServe during the backup operation.

For step-by-step instructions on running a table restore, see Restore and Recover One or More Database Table(s).

Backup Considerations

Before performing any backup procedures for this agent, review the following information:

• For online database backups the database must be in ARCHIVELOG mode.
• Oracle selective online full backup jobs will immediately fail if there are any job-related failures.
• It is recommended that users do not kill Oracle backup jobs, since it may cause RMAN and/or Cloragent exception errors.
• Users should not run several console-initiated RMAN jobs for the same instance at the same time for Oracle clients running on Windows platforms. Limit RMAN jobs to run one at a time in the CommCell Console and scheduler.
• Different SID and database names for Oracle instances are supported for Oracle command line backups.
• When the Data Files per BFS parameter is set to a value greater than 32 on the Subclient Properties (Backup Arguments) dialog, in order to back up more than 32 files per bundle at a time, the following parameter line is added inside the RMAN script: set limit channel ch1 maxopenfiles = nn
  Increasing the bundle size may improve the backup performance on large enterprise servers, but may hinder performance on smaller systems with limited resources.
• The incremental backup type is not supported by the Oracle Database application for Oracle 9.2 Standard Edition, and therefore is not supported by the Oracle iDataAgent. If you are using the Standard Edition of Oracle, you will need to run full backups.
• Oracle recommends that it is mandatory to do a Incremental Level 0 backup (which equates to a Full backup) after adding new tablespaces and datafiles to the database. If this is not done, the next Incremental backup would fail, because the Oracle Recovery Manager will not be able to find the parent files for the new tablespaces and datafiles.
• If you perform a backup of the default subclient, without changing its default properties, the backup would include all the objects in the database, including any new objects that may have been created.

  If you have created subclients for either online or offline databases, and have included the archived log files and control files in these subclients, you can create a complete backup of the database by backing up these subclients. If you have created a group of online subset subclients for the database, you must backup all of these subclients to create a complete backup. If you have created separate subclients for archive logs and control files, and if they are not included with the subclients defined for online databases, offline databases or subsets, then the subclients for archive logs and control files must also be backed up to create a complete backup.

• You can preview the backup and restore scripts that will be submitted to RMAN to back up or restore data on a client. Previewing the script before running a backup or restore is useful for identifying whether the selected backup or restore options will yield the desired result in the script. The script text can be previewed from the Backup Options and Restore Options dialogs, and provides the capability for you to copy the text from the display window for manual submission in RMAN, if desired.

  See Preview a Script for step-by-step instructions.

• You can run a validate job to ensure the integrity of the data and availability of the media before actually running a backup or restore job. When the validate option is selected on the Subclient Properties (Backup Arguments) tab or Advanced Restore Options (Options) tab, this will cause the system to simulate either a backup or restore job without using any media or over-writing the Oracle database. After the validate job completes, you can view the log file for the job to identify and correct any validation issues prior to running the backup or restore.

  For step-by-step instructions, see Validate a Backup or Restore.

• Review Performance Tuning - Oracle or Performance Tuning - Oracle RAC for details on setting configuration parameters to optimize backup and restore operations for your site.

• For Oracle on Linux platforms, review Avoiding Intermittent Backup Failures for Oracle on Linux Platforms for additional configuration steps that may be needed for your site.

• Multiple streams are supported for data protection and recovery operations with this agent; however, before utilizing multiple streams, you should understand how their use affects operations. For more information, see Streams.

• When creating/modifying an instance for Oracle or Oracle RAC iDataAgent, make sure that you do not enter a “/” at the end of the string for Oracle Home path. Due to limitations in the Oracle application, having a “/” at the end of the string for Oracle Home path can cause backups to fail occasionally.

• For Oracle and Oracle RAC iDataAgent, when you resume a backup job, if the subclient content includes the SP file, the backup job gets restarted from the beginning and all the data that was backed up previously gets backed up again. This causes an incorrect display of data transferred count in job details.

• If the Oracle offline backup with lights out option fails when you use the default value for Tries Number in the Subclient Properties (Backup Arguments) window, then increase the value to a number greater than or equal to 5.

• An Oracle offline backup will start up from the beginning (and not from the point of failure) if the backup fails and is then resumed.

• When you configure the Oracle database using RMAN, determine how long you need to retain the backup and recovery records in the control file and set the retention value using the database parameter CONTROL_FILE_RECORD_KEEP_TIME. By default, the value for this parameter is set to 7. This means that Oracle will maintain the backup and recovery information in the control file for a period of 7 days. Now, if you perform a point in time recovery to a period greater than 7 days, the restore operation fails. You can view the current setting of the CONTROL_FILE_RECORD_KEEP_TIME parameter as follows:

  SQL> show parameter CONTROL_FILE_RECORD_KEEP_TIME;

  It is always recommended that you set the CONTROL_FILE_RECORD_KEEP_TIME parameter to a value greater than the RMAN retention period. Otherwise, you will have backups available in the backup media without any related backup information in the control file. For more information, refer Oracle documentation.

• For Oracle and Oracle RAC iDataAgents, if the Oracle Instance (SID) name is different from the database name or if the Oracle Instance (SID) name configured in the CommCell is different from the actual instance name (case sensitive), then Oracle offline backups with lights out script may fail. In such cases, you need to select the Use SQL Connect option in the Subclient Properties (Backup Arguments) tab in order to connect to the database using the Connect String value configured for the instance in the Instance Properties (Details) tab. Also, make sure that the Connect String value does not include "/" when used with the Use SQL Connect option.

• When Oracle and DB2 iDataAgents are installed on the same client, make sure that both Oracle and DB2 users are part of the primary user groups.

• For Oracle and Oracle RAC iDataAgents, selective online full backup jobs are not preemptable nor restartable. Similarly, oracle log backup jobs that are submitted during selective online full backups (data phase) also cannot be preempted nor restarted.
• When restarting Oracle offline backup jobs, note that the job is restarted from the beginning rather than from the point of failure.

Back to Top