Overview - Oracle RAC iDataAgent


Choose from the following topics:


Introduction

The Oracle RAC iDataAgent works in conjunction with the Oracle RAC database, and it is designed primarily to do the following:

This iDataAgent allows you to group any desired number of Oracle iDataAgent instances under one or more Oracle RAC database logical entities. As such, Oracle backups and restores as well as other job types and functions (including Data Aging, Scheduling, Job Management) are all consolidated and easy to manage. This allows you to maintain your data irrespective of whether you add or remove Oracle iDataAgent instances from the RAC database.

The Oracle RAC iDataAgent also provides the following advantages:

Back to Top


Supported Data Types

Data Protection Operations for the following data types are supported by the Oracle RAC iDataAgent:

Data Protection Operations for all other data types not mentioned in the above list are not supported by the Oracle RAC iDataAgent, including:

Back to Top


Tree Levels in the Oracle RAC iDataAgent

Unlike most other agents, the Oracle RAC iDataAgent is not installed, and no level or icon is displayed for this agent in the CommCell Browser. Instead, you create one or more RAC pseudo-clients for this agent from the CommCell Console. As you create each pseudo-client, you concurrently create an instance for the pseudo-client. This instance is designed to include Oracle iDataAgent instances that have already been created. You can add, modify, or delete these instances. Once the pseudo-client instance is configured, a default subclient is created.  Once you do all this, the affected tree level may appear as follows in the CommCell Browser:

CVRAC: Pseudo-Client for Oracle RAC database node

cvrac: <user_defined_instance>:Instance for Pseudo-Client

tvdinner: Client for Oracle iDataAgent

Oracle: Agent


License Requirement

The Oracle RAC iDataAgent does not consume a license. However, an Oracle iDataAgent license is required for each Oracle RAC node on which you configure Oracle iDataAgent instances.

Back to Top


Databases, Instances, and Subclients

Before you back up data using the Oracle RAC iDataAgent, you must define the data that you want to back up and how this data should be backed up. Consider the following:

To determine the best strategy, you should ask the following questions: 

If your Oracle database is in the NOARCHIVELOG mode, you must back up the database offline. For an online backup of the database, it must be in ARCHIVELOG mode. If the database must be accessible, and you have a small backup window, you may want to run a series of online backups in which different portions of the database are backed up at different times. You may also want to combine all of these backup types in your backup strategy. Once you have determined your backup needs you can define your backup strategy by creating one or more subclients for the database. To perform this task effectively, you need to understand the key aspects of the CommCell architecture, most notably:

If at some later time you decide to change the way a client computer is backed up, you can always change the CommCell configuration, in whole or in part. You may also add new databases to be secured by the system, or remove databases currently secured.

Back to Top


Performance Tuning

Performance tuning parameters are a valuable tool for the recovery administrator to increase efficiency of backup and restore operations by avoiding throughput bottlenecks. The performance of Oracle backup and restore operations can be optimized through the appropriate configuration of RMAN parameter options provided in the Subclient Properties dialog box. A brief description of certain key performance tuning parameters and their recommended uses is provided below.

Data Files per BFS

The Data Files per BFS parameter defines the number of datafiles to be bundled in each RMAN backupset, for datafile backups. It is often used in conjunction with the Max Open Files parameter to establish the proper RMAN multiplexing factor for disk buffer allocation. For example, assume that you are backing up six datafiles with one RMAN channel. If FILESPERSET=6 and MAXOPENFILES=1, then the channel includes 6 datafiles in a backupset but does not multiplex the files because RMAN is not reading from more than one file simultaneously. The channel reads one file at a time and writes to the backup piece. In this case, the level of multiplexing is 1 and would result in relatively slower backups because of the throughput bottleneck. Ideally, the MAXOPENFILES parameter should be set in such a way that the number of files read simultaneously is just enough to utilize the output device fully. In this example, if FILESPERSET=6 and MAXOPENFILES=3, the level of multiplexing is 2 and would result in a quicker more efficient backup, especially when the output device is tape, by allowing RMAN to provide the proper disk buffer allocation. However, keep in mind that multiplexing too many files can decrease restore performance depending on the hardware configuration.

Archive Files per BFS

The Archive Files per BFS parameter defines the number of archive files to be bundled in each RMAN backupset, for archive log backups. Its use is similar to the Data Files per BFS parameter discussed above.

Max Backupset Size (KB)

The Max Backupset Size parameter defines the maximum allowable size for an RMAN backupset. It can be used to adjust performance for either partial restore or whole database restores. The proper setting depends on whether faster whole database restores or partial restores are required. A smaller MAXBACKUPSETSIZE will result in faster partial restores, however, whole database restores will be slower. A larger MAXBACKUPSETSIZE will result in faster whole database restores, but may not be optimal for partial restores. It is generally recommended that you avoid entering too small a value for this setting, which should be at least 2000 KB. The exception is the default value of 0, which means unlimited.

Max Open Files

The Max Open Files parameter defines the maximum number of concurrent open datafiles that RMAN can read from simultaneously during a backup operation. A smaller MAXOPENFILES setting results in faster performance on most systems. However, it should be used in conjunction with the Data Files per BFS or Archive Files per BFS parameters to achieve the most efficient RMAN multiplexing level for optimizing disk buffer allocation. The goal is to set the number of files read simultaneously to fully utilize the output device. See Data Files per BFS above for a discussion of how these parameters work together. Keep in mind that the default value for this parameter is 8.

See Configure Backup Arguments for step-by-step instructions. See also publications from Oracle Corporation on the topic of RMAN performance tuning for a more complete understanding of this subject.

Disk Ratio

Disk ratio enables RMAN to read data files across disks and group them in a backup set. For example, consider data files distributed across 10 disks that supply data at 10 bytes/second and a tape drive that needs 40 bytes/second to keep streaming. In this case, you can set the disk ratio value to 4, which will direct RMAN to include data files from 4 disks in each backup set. Disk ratio groups the data files into backup sets and distributes the backup load across disks. Even though disk ratio facilitates backup performance, you should keep in mind that more the number of disks from which data files are grouped, slower will be the restore performance. Hence, make sure that a minimum possible value is set for disk ratio.

 

Back to Top


Ensuring Successful Oracle Data Protection and Recovery Operations

The Oracle RAC iDataAgent provides the ability to validate the database, prior to actually running a data protection or recovery operation, to help ensure that Oracle backups and restores will run smoothly. A description of this feature is provided below.

Validate

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.

Back to Top


Disaster Recovery Considerations

Back to Top