How Oracle Adjusts the performance of Rman backup and recovery operations

RMAN is actually installed, and we don't usually need to make any adjustments to it. However, the Rman architecture also contains a number of components that, when they form a whole, must adjust the Rman settings to get the best performance from the backup process. Typically, Rman adjusts the inefficiencies of design to processing logic and physical database design, adjusts the media management library (media Management LIBRARY:MML), and adjusts the Rman and MML layers to better coexist with the physical devices that back up the database.

A Adjust the work before Rman

If Rman has a very long backup operation, this may not be an rman fault. In most cases, this may be a problem with the database or MML.

When you adjust the Rman and backup and recovery processes, you may also have a problem with long backup times. Although Rman often has problems, this is not necessarily an rman fault. It may be that the total bandwidth of the system is insufficient, and Rman is only one factor in this situation. The better the performance of the database, the better the performance of the RMAN backup operation.

1, can achieve the Rman performance

As mentioned in the Rman white Paper, the rate at which data can be backed up and recovered at tape is at 1TB per hour under current technical conditions. With the continuous development of tape backup technology, this rate is likely to become even greater.

2, the use of appropriate hardware

If you want higher backup performance, the first consideration is the configured backup hardware. Backup hardware may include tape devices and associated infrastructure (such as cables, automatic tape interfaces, and possibly MML layer software).

The backup media hardware determines the speed of the read-write device. The faster a device is written, the faster it will be backed up. In addition, the more devices that perform backup operations, the faster the backup will be. Increasing the use of the drive by Rman can almost linearly improve the efficiency of backup and restore operations. The ability to perform backup operations in parallel across multiple channels and backup devices is critical for fast backup of large Oracle databases.

Rman can benefit from parallel CPU resources, but only this, and adding more CPUs does not continue to improve performance significantly. This is completely different from using more backup devices. In most cases, using multiple backup devices can have a positive impact on backup and restore Windows than adding CPUs.

Most backup devices are asynchronous rather than synchronized. Asynchronous devices enable the backup server process to emit I/O instructions without waiting for I/O to complete. For example, an asynchronous operation allows a server process to issue a disk write instruction, which, while executing this instruction, can continue to populate the memory buffer to prepare for the next write operation. On the other hand, the synchronization device must wait for the backup operation to complete before any other work can be performed. Therefore, using asynchrony is more efficient than synchronizing devices.

Here are a few parameters for asynchronous operations:

The backup_tape_io_slaves parameter (the default is False) is set to tape I/O asynchronous. If you support asynchronous I/O to the tape backup device, we recommend that this parameter be set to True to start the setting. After you establish the Backup_tape_io_slaves parameter, you can define the size of the memory buffer by using the channel parameter of the Allocate channel command or the Configure Parm command.

The size of the tape buffer is determined when the channel is configured, and its default value is determined by the operating system, but typically 64kb. Use the Allocate channel command to set the size of the tape buffer to a different value. For optimal performance, we recommend that the size of the tape buffer be set to 256KB or greater. Such as:

Allocate Channel C1 device type SBT parms= "blksize=262144, env= (NB_ORA_CLASS=RMAN_ORCL)"

If you want to back up data on disk, we must determine if the operating system supports asynchronous I/O. If supported, Oracle automatically uses the capabilities of asynchronous I/O, and if not, sets the Oracle-supplied dbwr_io_slaves parameter to a value other than 0, and Oracle simulates asynchronous I/O to the disk by starting multiple DBWR processes.

When you configure Dbwr_io_slaves or backup_tape_io_slaves, you may also need to create a large pool. This will help eliminate the problem of shared pool contention and memory allocation problems that occur along with shared pooling when backup_tape_io_slaves is enabled. If you use the automatic shared Memory Management (ASMM) in Oracle 10g, Oracle manages the memory allocation for the shared pool. If you need to manually set up the large pool, the total size of the disk buffers is limited to 16MB per channel. The formula for setting the Large_pool_size parameter for a backup is as follows:

Large_pool_size= (number of allocated channels) * (16mb+size of tape buffer)

If Dbwr_io_slaves and backup_tape_io_slaves are not configured. Rman will not use the large pool. In general, these parameter settings need to be configured to obtain good performance from Rman unless the system does not support asynchronous I/O.

3. Adjust the database

Poorly tuned databases also have a very negative impact on backup time. Some database adjustment issues can also significantly affect the restore time.

(1) Adjust I/O

I/O contention lowers the speed of the system. Poor I/O distribution affects not only the performance of the database, but also the backup and restore times, because Rman is another process (or multiple processes in parallel) that is competing for I/O time on the device.

Backup is a read-intensive (read-intensive) operation. If I/O distribution is poor, not only will rman performance be affected, but users will also be affected at least during backup operations. If all recoveries are full database restores, the recovery operation may be simpler. However, if only one data file or one tablespace is restored, poor I/O distribution can be found to affect the recovery window and the user because the database is open and in use. Fundamentally, poor I/O distribution can affect not only the day-to-day database users, but also the backup and restore operations for a longer period of time.

(2) Adjust the use of memory

As with all Oracle processes, RMAN also needs to use memory. When the Rman operation is started, a buffer is allocated for the Rman operation, and we can determine the size of the buffer based on the following factors:

(a) RMAN backup and recovery multiplexing impact

(b) Type of equipment used

(c) Number of channels allocated during Operation

(2.1) Allocating memory buffers for disk devices

When backing up data on a disk device, RMAN can allocate up to 16MB of memory, which is allocated based on the reuse level. If the reuse level is 4 or below, RMAN allocates 16 buffers with a size of 1MB. These 1MB buffers are allocated between the number of data files to be backed up. Therefore, if the Filesperset parameter (setting the reuse level) is set to 2, each data file is allocated 8 1MB buffers.

If the Filesperset parameter is set to a number between 5 and 8, RMAN allocates a buffer of 512KB size and distributes it evenly to different data files, at which point the allocated memory buffer does not exceed 16MB. If the reuse level is greater than 8, each data file loves you to be assigned a buffer of 4 128kb, and the total buffer allocated for each data file is 512KB.

(2.2) allocating memory buffers for SBT devices

When backing up data on a SBT device, Rman allocates 4 buffers for each allocated channel. The size of these buffers is typically 256kb, so the total memory allocated for each channel is 1MB. You can use the parms and blkzise parameters of the allocate or send commands to manage the buffer size.

This memory is usually allocated from the PGA, but if the backup_tape_to_slaves parameter is set to True, the SGA is required unless the large pool is assigned, in which case the large pool is used. Therefore, if you want to configure I/O dependencies (which should typically be configured with I/O dependencies when backing up data on a SBT device), you should configure a large pool to reduce the large pool's requirements for the entire memory.

(3) Adjust SQL

Poor SQL statement operations have a negative impact on the entire database and the system where the database resides. Any negative impact on the database can also have a negative impact on the backup operation. We should adjust the SQL operation to reduce the number of I/O required for the lock (logically and physically) and schedule the backup operation during system idle time.

(4) Adjust the environment

To confirm that the backup schedule does not conflict with I/O intensive database operations, such as data loading or reporting. In addition, if the backup operation takes too long, consider using an incremental backup strategy, analyzing the database and determining whether there is a read-only tablespace, so that you do not need to back up the read-only table space frequently. If you run the database in archive mode, you can also consider staggered backup of the table space on different dates to reduce the time for the entire backup operation, but this is also at the expense of longer recovery times.

(5) Adjust backup and recovery policies

If the database is quite large, we cannot just execute a backup DATABASE command to back up all the set of files, but we should take a block-back strategy. Consider using a separate backup tablespace or backup datafile command to back up related data files that might need to be restored together, and assigning a specific channel to those backups, which reduces the number of tapes exchanged during recovery operations. The fastest recovery of the relevant data files. Such as: