Question:  What is the RMAN backup optimization feature and how does it work?

Answer:  The RMAN backup optimization feature is controlled by these commands:

RMAN> configure backup optimization on;
RMAN> configure backup optimization off;

When you turn on backup optimization, all backup commands will skip backups of any file if it has not changed and if it has already been backed up to the allocated device type.  A file can be any dbf file, an archived redo log or an RMAN "backup set".  Here are some of the main features of the RMAN configure backup optimization on command:

• In order to back up the flash recovery area itself using RMAN, you must set configure backup optimization to ON.
  
• Setting backup optimization on stops the backups of Read Only Tablespaces (ROT), whenever a valid backup of the tablespace already exists in the RMAN catalog database.
  
• If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the allocated device.

• In order to back up the flash recovery area itself using RMAN, you must set configure backup optimization to ON.
  
  
• Setting backup optimization on stops the backups of Read Only Tablespaces (ROT), whenever a valid backup of the tablespace already exists in the RMAN catalog database.
  
  
• If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the allocated device.

Also see Oracle Backup & Recovery: Expert secrets for using RMAN and Data Pump for more on RMAN tuning techniques.

Additional RMAN tuning tips

There is always a need to optimize things and this is a goal which is shared by all the administrators. When it comes to RMAN, the same goal is anticipated by the administrators on how they can improve the performance of the backups and recoveries done via RMAN. It is possible to make RMAN take a backup of multiple terabytes of the database in a blink of an eye! Though it is not a bad thing to have expectations, it is important to make realistic goals.

Imagine that you are walking on a very busy road filled with lots of people and you are late reaching your office. What would you do to optimize this situation? Buy better, more expensive shoes? Would you blame your shoes for being slow and, therefore, making you late? No, it is not the shoes but the traffic on the road which is causing you to be slower. Maybe the road is not smooth and walking very fast over it is not possible.

This is the case with RMAN. It is the shoe that you are wearing. Trying to make it better will not always help; not that it will never help because soccer shoes will not let you walk properly on a road! However, there are many other moving pieces which would actually impact the performance. This section will cover some guidelines which you can use to optimize the performance of RMAN.

It is All About I/O

As stated before, it is not the shoe that causes lower quality, but either the traffic on the road or the road itself being so messy! The poor shoe becomes the culprit despite the fact that it is actually the victim. So is the case with RMAN. It deals with many moving pieces and one of the most important terms in those moving pieces is the I/O; either while reading from the source of the backup or writing the same to the target device, it is I/O all around! When RMAN is doing the operation of the backup, it will essentially be reading the information from the source of the media. The read information is then sent for final processing and copied into the memory area from where it is written out to the output device. The read phase of RMAN is the phase which can be really tricky and is governed by several factors.

RMAN can read the data from multiple sources as well. What this means is that it is possible for RMAN to read two datafiles at the same time and then write them to an output device in the form of a backup piece. This is governed primarily by the filesperset parameterwhich tells RMAN how many files can be part of a backup set. Another parameter which is a channel's property, maxopenfiles, tells how many files can be opened by RMAN for simultaneous read.  So when the multiplexing limits are calculated, it is a minimum of this number and filesperset. The defaults of filesperset and maxopenfiles are 64 and 8.

Based on the level of multiplexing, RMAN allocates the number of buffers and also decides the size of the allocated memory buffer. The number of buffers remains fixed to 16 and a size of 1 MB with the multiplexing level 4 or less. With the level greater than 4, the number becomes varied and also the size of the buffers is reduced from 1 MB to 512 KB or 128 KB. For ASM, this is a fixed equivalent to the number of the disks within the disk group.

For backups done over the tape drives, each RMAN channel working over that device allocates four buffers and each buffer is sized to 1 MB of memory. So if you carefully choose settings for the multiplexing which further govern the overall memory consumed by RMAN, it can give you a control over the memory consumed by it. Without unnecessarily consuming the memory, RMAN's impact over the system is minimal and with a planned multiplexing rate, backup operations also are faster. Since the memory buffers are allocated from PGA, having a control over their size also keeps your PGA tuned and does not let it overgrow.