Parallelization of Backup Sets

Backup sets, backup pieces, and channels

Channel parallelism

The number of channels establishes the maximum number of RMAN server sessions that can perform work concurrently for a device type. You can configure persistent parallelism or allocate channels manually for one job.

Configure automatic channels

The following command configures RMAN to allocate four disk channels automatically whenever a backup or restore operation uses the disk device type:

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

After this configuration, a command such as BACKUP DATABASE; can use as many as four disk channels. RMAN distributes eligible input files and backup sets among the channels according to its internal scheduling algorithm.

Allocate channels for one job

Manual allocation applies only within the current RUN block. It is useful when a job needs settings that should not become part of the persistent RMAN configuration.

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK;
  BACKUP DATABASE;
}

In this example, two server sessions can produce separate backup sets concurrently. When the RUN block ends, RMAN releases both channels.

Adding channels does not guarantee a proportional improvement in performance. A job with four channels still needs enough input files or file sections to keep four sessions busy. Storage throughput, CPU capacity, network bandwidth, media-manager limits, and contention with database workloads can also constrain the effective parallelism.

How RMAN creates enough backup sets

Each backupSpec in a BACKUP command produces at least one backup set. RMAN decides the final number and size of the sets, but several options let you influence how the work is divided.

Control file grouping with FILESPERSET

The FILESPERSET operand sets the maximum number of input files that RMAN can place in one backup set. Its default value is 64. A smaller value can cause RMAN to create more backup sets, which may expose more independent work to the available channels.

BACKUP DATABASE FILESPERSET 8;

This command limits each backup set to eight input files. It does not require every set to contain exactly eight files. The final set can contain fewer files, and RMAN can create additional sets when required by the number of files, channels, or other backup options.

Reducing FILESPERSET is not automatically better. More backup sets can improve channel utilization, but excessive fragmentation creates more files and repository records to manage. The appropriate value depends on the number and size of the input files, the available channels, and the characteristics of the backup destination.

Control backup-set and piece size

MAXSETSIZE limits the total size of a backup set. This setting can indirectly force RMAN to create additional sets. MAXPIECESIZE limits the size of each physical backup piece and is configured on a channel. If a non-multisection backup set exceeds the piece limit, the same channel writes additional pieces serially until the set is complete.

CONFIGURE MAXSETSIZE TO 100G;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 20G;

These options solve different storage problems. Use MAXSETSIZE to limit the logical set and MAXPIECESIZE when a file system or media manager imposes a maximum physical file size. Creating several pieces because of MAXPIECESIZE does not, by itself, make one channel write those pieces in parallel.

Multiplexing several input files

Within one channel, RMAN can read blocks from several input files simultaneously and write the blocks into the same backup piece. This process is called backup-set multiplexing. Multiplexing can help one channel keep its output stream busy when individual source files cannot supply data quickly enough.

Two settings determine the practical multiplexing level:

• FILESPERSET limits the number of files included in a backup set. The default is 64.
• MAXOPENFILES limits the number of input files that a channel reads concurrently. The default is 8.

The effective multiplexing level is the smallest of MAXOPENFILES, the number of files in the backup set, and the number of files assigned to the channel.

Assume that one channel receives 10 data files, FILESPERSET is 4, and MAXOPENFILES is 8. RMAN places no more than four files in each set. The channel can therefore read four files concurrently and interleave their blocks in one piece. After completing that set, the channel begins another set for the remaining files.

CONFIGURE CHANNEL DEVICE TYPE DISK MAXOPENFILES 8;
BACKUP DATABASE FILESPERSET 4;

High multiplexing is not always desirable. Interleaved input can reduce the sequential nature of disk I/O, and restoring one file may require RMAN to read through blocks belonging to other files in the same piece. For disk backups, a moderate multiplexing level often provides a better balance than the highest possible value.

RMAN multiplexing is also different from media-manager multiplexing. RMAN multiplexing combines blocks from multiple database files inside one RMAN backup piece. Media-manager multiplexing combines output from several RMAN channels into one sequential device stream. Oracle recommends that media-manager multiplexing not be used for RMAN backups.

Multisection backups for one large data file

Channel parallelism works naturally when a database contains many files. RMAN can assign different files to different channels. A database can still have an imbalance, however, when one very large data file takes much longer to back up than all the others. After the smaller files finish, several channels may sit idle while one channel continues reading the large file.

The SECTION SIZE operand addresses this problem. RMAN divides the large file into contiguous ranges of blocks called file sections. Separate channels can back up those sections concurrently, with each channel producing one backup piece for its assigned section.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
BACKUP DATAFILE 5 SECTION SIZE 800M;

If data file 5 is large enough, as many as four disk channels can process different 800 MB sections at the same time. The pieces remain part of one multisection backup set. A successfully completed multisection backup does not leave a partial data file in any completed backup set.

RMAN applies several safeguards. If the requested section size is larger than the file, RMAN does not create a multisection backup for that file. If the requested size would create more than 256 sections, RMAN increases the section size so the file has exactly 256 sections. You cannot combine SECTION SIZE with MAXPIECESIZE in the same backup.

A multisection data file is not multiplexed with other data files or file sections. This keeps the meaning of each section piece clear and allows RMAN to coordinate the sections as one complete file backup.

Principles in action

To understand the actual degree of parallel execution in a backup job, evaluate the following factors together:

1. Allocated channels: The channel count establishes the maximum number of RMAN server sessions that can perform work concurrently for the selected device type.
2. Available backup sets: Separate backup sets provide independent units of work that RMAN can assign to separate channels.
3. Input-file grouping: FILESPERSET influences how many files belong to one set and can therefore affect how many sets RMAN creates.
4. Multiplexing: FILESPERSET and MAXOPENFILES determine how many input files one channel can read into the same piece concurrently.
5. Large-file sections: SECTION SIZE lets several channels work on one large data file instead of leaving all but one channel idle.
6. Storage capacity: Parallel channels compete for disk, network, CPU, and media-manager resources. The slowest shared resource can become the real limit.

Channels and backup pieces

The following example uses three channels and sets FILESPERSET to 2 for archived redo logs. Each backup set can contain no more than two logs.

With five archived logs, RMAN creates three backup sets: two sets contain two logs, and the last set contains one. Three channels can process those three sets concurrently.

With nine archived logs, RMAN creates five backup sets. Only three sets can begin at once because only three channels are available. When a channel completes its first set, RMAN can assign another pending set to that channel. Parallelism remains limited to three active channels even though the job contains five sets.

This distinction is important: the number of backup sets controls how much independent work is available, while the channel count controls how much of that work can run at one time.

Assign a backup specification to a specific channel

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK
    FORMAT '/backup/location_a/%U';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK
    FORMAT '/backup/location_b/%U';

  BACKUP CHANNEL c1 DATABASE FILESPERSET 4;
  BACKUP CHANNEL c2 ARCHIVELOG ALL FILESPERSET 2;
}

Channel-specific backup commands intentionally reduce RMAN's scheduling flexibility. If a specification is bound to c1, RMAN cannot move that work to c2 simply because c2 becomes available first. Use explicit channel assignments when the destination or device requirement is more important than automatic load balancing.

Choosing a practical configuration

Begin by matching channel parallelism to independent storage paths and the throughput the destination can sustain. Then confirm that the job creates enough backup sets to keep those channels occupied. Keep multiplexing moderate unless testing demonstrates that a higher level improves throughput. For unusually large data files, use SECTION SIZE so that extra channels can contribute to the same file backup.

Measure the result rather than assuming that more parallelism is always faster. Review RMAN job output, elapsed time, channel activity, and storage utilization. Increase or decrease the channel count and grouping options based on observed bottlenecks.

In the next lesson, you will learn more about backup sets for data files.