Oracle: Agent
<user_defined_instance>: Instance
Choose from the following topics:
Related Topics:
The Oracle database is comprised of several objects. These objects can be backed up by the Oracle iDataAgent. For more information on the Oracle objects, refer to your Oracle documentation.
Data Protection Operations for the following data types are supported by the Oracle iDataAgent:
Data Protection Operations for all other data types not mentioned in the above list are not supported by the Oracle iDataAgent, including:
When the Oracle iDataAgent is installed, the following levels are automatically created in the CommCell Browser.
|
|
|
|
bootes: Client Oracle: Agent <user_defined_instance>: Instance |
|
|
|
In order to run the first backup, instances must be added. Each instance creates a default subclient. |
To perform a data protection operation using this Agent a specific Product License must be available in the CommServe® Server.
Review general license requirements included in License Administration. Also, View All Licenses provides step-by-step instructions on how to view the license information.
During installation, the Oracle iDataAgent software establishes the Oracle iDataAgent. Before you backup data, you must however, 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 backup 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.
See also: Establishing Parallel Data Protection Operations Using Subclients
Oracle instances can be moved from one client computer to another within a CommCell. See Moving an Oracle Instance for more information.
In addition to the Oracle database, there may be Oracle application files stored on the computer (that is, the Oracle client). Such data is not backed up by the Oracle iDataAgent. To secure such data from an Oracle client, you must back it up using the appropriate iDataAgent for the computer’s file system.
The Oracle iDataAgent supports the ability to perform backups and restores across clients from the RMAN Command Line. For more information, see Third-Party Command Line Operations.
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.
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.
The Oracle iDataAgent provides the ability to preview backup and restore scripts as well as validate the database, prior to actually running a data protection or recovery operation, to help ensure that Oracle backups and restores will run smoothly. Descriptions of these features are provided below.
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.
Consider the following when you are planning for a full system restore of the Oracle database in the event of a destroyed or damaged client: