Parallelizing RMAN Image Copies in Oracle 26ai

Yes. Oracle AI Database 26ai Recovery Manager (RMAN) can create image copies in parallel. Multiple disk channels can copy different files concurrently, and the SECTION SIZE clause can divide one large data file among several channels. A multisection operation still produces one completed image-copy file for each source data file.

This lesson combines the channel concepts from Lesson 4 with the BACKUP AS COPY command introduced in Lessons 5 and 6. An RMAN channel is a database server session that performs backup and recovery I/O. Several channels create several potential work streams, but the amount of work that can actually run at once depends on the files or file sections selected by the command.

Parallelism is a performance technique, not a backup format. Image copies remain exact disk copies with a one-source-file-to-one-output-file relationship. Parallel operation does not combine several data files into one piece, create duplicate copies, compress the output, or guarantee a shorter backup window.

RMAN can expose parallel work at the file level or inside one large data file. Distinguishing these levels prevents a common misconception: allocating four channels does not mean that RMAN will automatically divide every file among four sessions.

Two ways RMAN can parallelize image-copy creation

Parallelism type	Unit assigned to a channel	When it helps	Result
File-level	One complete file copy at a time	The backup selects several eligible files	One image copy for every selected source file
Multisection	One section of a large data file	One or more large files would otherwise limit channel use	One completed copy for every source data file

Without SECTION SIZE, one source file is processed by one channel at a time. If a database contains many data files, RMAN can assign different files to several channels. If a backup selects only one data file, only one channel has a complete file to copy, and the other channels may remain idle.

With SECTION SIZE, RMAN divides a sufficiently large data file into contiguous sections. Different channels can process those sections concurrently. File-level and multisection parallelism can operate in the same database backup: RMAN can schedule several files while also dividing eligible large files into sections.

This behavior is not backup-set multiplexing. An image copy never intermingles blocks from several source data files. Each completed copy continues to represent exactly one source file.

Use CONFIGURE DEVICE TYPE DISK PARALLELISM to establish persistent automatic-channel parallelism. The following example asks RMAN to allocate four automatic disk channels for eligible operations and explicitly creates database image copies:

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
BACKUP AS COPY DEVICE TYPE DISK
  DATABASE TAG 'PARALLEL_COPY';

The parallelism setting persists across RMAN sessions until it is changed or cleared. When the backup runs, RMAN automatically allocates up to four disk channels and distributes eligible files among them. Each channel creates one image copy at a time. After completing a copy, the channel can accept another file while the job continues.

The configured value is an upper bound on concurrent disk work. If the command selects only two data files and does not use multisection processing, only two complete file copies can run concurrently. The remaining channels do not manufacture additional work. Similarly, storage or host bottlenecks can prevent four channels from delivering four times the throughput of one channel.

AS COPY explicitly selects image-copy output. It is not necessary to change the persistent disk backup type when the command contains this clause. A site that routinely creates image copies can configure that output type separately:

CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
SHOW ALL;

This second configuration is independent of the parallelism value and affects later disk backups. Because both settings are persistent, a DBA should not change them merely to demonstrate a lesson. SHOW ALL displays the current RMAN configuration so the original and proposed settings can be reviewed.

Numbered automatic channels can use separate destination formats. This design can improve throughput when the paths lead to independent file systems, storage devices, or other I/O resources:

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/backup01/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/backup02/%U';

BACKUP AS COPY DEVICE TYPE DISK DATABASE;

RMAN numbers automatic channels from 1 through the configured parallelism value. Output assigned to channel 1 uses the first format, while work assigned to channel 2 uses the second. The %U substitution variable supplies an RMAN-generated name suitable for the selected copy type.

Both directories must exist, be writable by the Oracle database process, and have enough capacity for the image copies assigned to them. Image copies preserve complete file sizes, so capacity planning must account for every selected source file and any copies already retained.

Different pathnames do not necessarily mean independent hardware. Two directories may reside on the same volume, controller, storage pool, or network connection. In that case, adding channels can increase contention without increasing useful throughput. Conversely, ASM or a striped file system may benefit from multiple channels even when all output uses one logical destination. The result must be measured in the actual environment.

Manual channels provide job-scoped parallelism and channel attributes. Each ALLOCATE CHANNEL command must appear inside a RUN block. The following job allocates two disk channels, assigns a destination to each, and creates image copies of the data files in two tablespaces:

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup01/%U';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup02/%U';

  BACKUP AS COPY TABLESPACE SYSTEM, users;
}

The channels exist for this RUN block and are released when the job ends. RMAN assigns eligible data files to the available channels. If more than two files must be copied, each channel can receive another file after its current copy finishes.

Manual allocation is useful for a one-time job or when the channels require settings that should not become persistent configuration. It is not required for every parallel backup. Automatic channels are often clearer for a repeatable policy because the BACKUP command can use the approved configuration without repeating the allocation statements.

RMAN also supports a CHANNEL operand that can constrain selected backup work to a named channel. This can be useful for a carefully designed storage layout, but unnecessary pinning can produce an imbalanced job. Let RMAN schedule the files unless a tested requirement calls for specific channel assignments.

Each channel operates on one image copy at a time. Suppose a command selects six similarly sized data files and three disk channels are available. RMAN can begin as many as three copies concurrently. When a channel finishes a copy, RMAN can assign one of the remaining files to that channel.

Conceptual file-level concurrency

Available channels	Eligible files	Maximum initial file copies	Likely limitation
1	6	1	Serial processing
3	6	3	Storage throughput and file-size balance
6	3	3	Only three complete files are available
4	1	1 without SECTION SIZE	One large file limits parallel work

The values in the table are scheduling limits, not performance promises. File sizes are rarely equal. Several small files may finish quickly, leaving one channel to process the largest file while the others become idle. This tail effect can dominate the backup's elapsed time.

The channel count therefore does not, by itself, determine the observed degree of parallelism. RMAN also needs enough eligible files or file sections, and the storage path must sustain the combined workload. Multisection processing addresses the scheduling problem when one large data file would otherwise keep only one channel busy.

The SECTION SIZE clause divides an eligible data file into contiguous ranges of blocks. Multiple channels can process different sections of that file concurrently:

CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

BACKUP AS COPY DEVICE TYPE DISK
  SECTION SIZE 500M
  DATAFILE 5;

In this example, RMAN attempts to divide data file 5 into sections of approximately 500 MB. Up to four available channels can work on separate sections. When all sections complete, the result is one image-copy file for data file 5. The sections are units of work during creation, not independent permanent copies or backup pieces.

Multisection image copies require the target database COMPATIBLE setting to be 12.0.0 or higher. A normally configured Oracle AI Database 26ai environment satisfies that minimum, but compatibility should still be verified when a database has been upgraded or retains an older setting.

RMAN adjusts the operation when the proposed section size is not useful:

• If the specified section size is larger than the data file, RMAN does not use multisection processing for that file.
• If the value would produce more than 256 sections, RMAN increases the effective section size so the file has exactly 256 sections.
• If there are more sections than channels, each channel processes additional sections as it becomes available.
• If there are fewer usable sections than channels, some channels cannot participate in that file's copy.

SECTION SIZE is intended for eligible data files. Control-file and archived-redo-log image copies should not be presented as multisection candidates. It is also not ordinary file-level parallelism: it specifically makes sections of one large file available to several channels.

Oracle AI Database uses a multitenant architecture. When RMAN is connected to the CDB root as a common user with the required administrative privilege, a database backup can select data files across the target CDB. The following command gives RMAN both file-level and multisection opportunities:

BACKUP AS COPY DEVICE TYPE DISK
  SECTION SIZE 1G
  DATABASE TAG 'CDB_PARALLEL_COPY';

RMAN can distribute different CDB data files across available channels and divide sufficiently large eligible files into sections. Regardless of the internal scheduling, the output remains one image copy for each selected source data file.

A root-connected administrator can also select one or more pluggable databases. This example creates copies for one PDB and allows large data files to be divided into 500 MB sections:

BACKUP AS COPY DEVICE TYPE DISK
  SECTION SIZE 500M
  PLUGGABLE DATABASE hr_pdb
  TAG 'HRPDB_PARALLEL_COPY';

The connection scope and privileges determine whether a command operates on the CDB or selected PDBs. RMAN administrative work commonly uses the SYSBACKUP privilege. Parallelism changes how RMAN schedules the work, not which containers or data files the backup command is authorized to select.

Several options associated with backup sets do not apply to image copies. Keeping these boundaries clear prevents invalid commands and incorrect capacity expectations.

Features related to parallel image-copy creation

Feature	Applies to BACKUP AS COPY?	Explanation
Multiple disk channels	Yes	Channels can create separate copies or eligible file sections concurrently
SECTION SIZE	Yes, for eligible data files	Several channels can process one large source file
COPIES duplexing	No	The COPIES operand with AS COPY produces an RMAN error
Backup-set multiplexing	No	Blocks from different source files are not intermingled
Binary compression	No	AS COMPRESSED BACKUPSET creates backup sets rather than image copies
SBT destination	No	RMAN image copies can exist only on disk-accessible storage

Parallelism controls concurrent work; it does not create redundant copies. Do not use BACKUP AS COPY COPIES 2, because Oracle documents that COPIES does not apply with AS COPY. If a recovery design requires another image copy, use a separately planned and supported copy or replication process and account for its I/O, capacity, consistency, and repository implications.

Similarly, FILESPERSET, MAXSETSIZE, backup-piece multiplexing, and binary compression describe backup-set behavior. They should not be used to explain or tune image-copy output.

The best degree of parallelism is specific to the database and storage environment. Begin with a measured baseline, then increase the channel count only while throughput, elapsed time, and production impact remain acceptable. Four channels in an example do not establish four as a universal optimum.

Evaluate the complete data path:

• Read throughput of the source data-file storage
• Write throughput and capacity of the destination file system or ASM disk group
• Shared storage controllers, volumes, caches, and queue depth
• Network bandwidth and latency for network-mounted disk destinations
• Database-host CPU, memory, process capacity, and concurrent workload
• The number and size distribution of selected data files

More channels can reduce elapsed time when the system has unused I/O capacity. Too many channels can increase contention, context switching, and interference with database sessions. A higher setting can therefore produce no improvement or make the backup slower.

Use configuration, repository, and runtime evidence to evaluate the result:

SHOW ALL;
LIST COPY OF DATABASE;

SHOW ALL confirms persistent device and channel settings. LIST COPY OF DATABASE reports the resulting data-file copy records known to RMAN. The RMAN job output identifies allocated channels and shows which sessions received work.

The V$RMAN_STATUS view reports RMAN job and operation status. V$SESSION_LONGOPS can expose progress for eligible long-running RMAN operations. Compare elapsed time and throughput with the baseline rather than assuming that configured channels were all busy or useful.

1. Confirm the CDB or PDB scope and identify the data files selected by the backup.
2. Record the current RMAN device, backup-type, channel, and parallelism configuration.
3. Measure a representative baseline with the existing channel count.
4. Choose automatic or manual disk channels and verify each destination's permissions and capacity.
5. Add SECTION SIZE only when large data files limit channel utilization.
6. Monitor channel assignments, throughput, elapsed time, and the impact on production workloads.
7. Use the RMAN job result and LIST COPY to verify that the expected copies were recorded.
8. Test restore and recovery after changing the backup design. Faster creation alone does not prove recoverability.

Remember that CONFIGURE settings persist across RMAN sessions. If a test changed production configuration, restore the approved original value rather than blindly setting an arbitrary default. Manual channels are released at the end of their job and can be preferable when the test should not alter persistent automatic-channel settings.

Use multiple disk channels to copy different files concurrently. Use SECTION SIZE when several channels need to process one large data file. The effective degree of parallelism is limited by the available channels, eligible work, and the throughput the system can sustain.

In the next lesson, you will examine operating-system image backups and the consistency safeguards required when file copies are created outside RMAN.