Using RMAN Channels for Backup Operations

An RMAN channel is a connection from the RMAN client to a database server session. The server session performs backup, restore, and recovery I/O on behalf of RMAN. A channel has a device type, connection information, and operational settings that determine where and how backup data is read or written.

Lesson 3 introduced RMAN backup sets and image copies. This lesson explains the server-side I/O streams that create, read, and restore those backups. It also distinguishes automatic channel allocation, which is normally best for recurring operations, from manual allocation for a single job. These concepts apply to Oracle AI Database 26ai whether the protected target is an entire container database (CDB) or a supported pluggable database (PDB) scope.

How RMAN Channels Work

The RMAN client and a channel have different responsibilities. The client parses RMAN commands, directs the job, displays messages, and records job status in the RMAN repository. It does not carry the database blocks being backed up. The channel corresponds to a server session in the target or auxiliary database instance, and that server session performs the data movement and processing required by the operation.

Two paths are therefore involved. The control path carries instructions from the RMAN client to the channel server session. The backup data path runs between the database instance and the configured backup destination. During a backup, a channel reads Oracle blocks from the target database, processes them as required, and writes a backup piece or image copy. During a restore, a channel reads backup data and writes the restored database files. The backup bytes do not pass through the RMAN client process.

Each allocated channel represents one stream of backup or restore work. A job with one channel has one available I/O stream. A job with several channels can process several eligible units of work concurrently. RMAN assigns work to channels as it becomes available, so a channel is not a permanent reservation for one particular data file. This distinction becomes important when sizing parallelism and interpreting a multi-channel diagram.

DISK and SBT Channel Types

RMAN supports two channel device types: DISK and SBT. The device type selects the I/O interface that a channel server session uses. Tape is not a third device type. A tape library is one possible destination behind the System Backup to Tape interface and its media-management software.

A DISK channel creates files that the target database instance can access as disk files. This includes conventional file systems, ASM storage, and the Fast Recovery Area. RMAN can create both backup sets and image copies on disk. Because an image copy has the same logical structure as the source data file, control file, or archived redo log, image-copy operations require a disk-accessible destination.

An SBT channel passes a backup byte stream to a supported SBT library or media manager. The implementation determines whether that stream is stored in cloud object storage, a Recovery Appliance service, or a physical tape library. Oracle AI Database 26ai includes native SBT libraries for supported Oracle Cloud Infrastructure, Amazon S3, and Microsoft Azure Blob Storage integrations. Vendor-specific configuration remains dependent on the library or service in use. SBT channels create and restore backup sets, not RMAN image copies.

Automatic Channel Allocation

Automatic allocation is the preferred approach for routine, repeatable backup and recovery jobs. RMAN is preconfigured with a default DISK channel, so a basic disk backup can run without an explicit ALLOCATE CHANNEL command. Administrators use CONFIGURE commands to replace or extend the defaults with persistent settings for the target database.

Persistent RMAN configuration is stored in the target database control file and, when a recovery catalog is used, represented in the catalog. When a compatible job begins, RMAN allocates the required configured channels, assigns work to them, and releases them after the command completes. The SHOW ALL command displays the effective configuration, including settings still at their defaults.

CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
SHOW ALL;

This example selects DISK as the default device and configures a parallelism of three for that device type. A compatible job can therefore receive three automatic DISK channels. The setting creates the opportunity for three concurrent I/O streams, but it does not promise that the job will finish three times faster. The amount of eligible work and the capacity of the source, CPU, network, and destination determine the practical result.

Numbered automatic-channel configurations can apply different settings to individual channels. For example, three automatic channels can send their output to three disk locations:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%U';
CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%U';
CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%U';

The paths are examples. Each path must exist, be writable by the Oracle software owner, and have enough capacity for its assigned output. Three directories do not necessarily represent three independent I/O resources. If all three reside on the same constrained storage device, increasing the channel count can add contention without improving throughput.

An automatic SBT channel can also be configured persistently. Its PARMS, library location, credentials, and other attributes depend on the selected SBT implementation. The appropriate values should come from the documentation for that service or media manager rather than from a generic RMAN example.

Manual Channel Allocation

Manual allocation is appropriate when one job needs temporary settings that should not change the persistent RMAN configuration. Examples include testing a destination, creating a one-time copy in specific locations, using job-specific SBT parameters, or selecting a different degree of parallelism for one operation.

The ALLOCATE CHANNEL command must appear inside a RUN block. Each command gives the channel a job-local name, such as c1, and specifies its device type and optional settings. Manually allocated channels exist only for that RUN block. RMAN releases them when the block finishes. For the applicable device type, the manual channels override configured automatic channels during that job.

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK
    FORMAT '/disk1/%U';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK
    FORMAT '/disk2/%U';
  ALLOCATE CHANNEL c3 DEVICE TYPE DISK
    FORMAT '/disk3/%U';
  BACKUP AS COPY DATABASE;
}

In this example, the RMAN client allocates three DISK channels. The target database starts three channel server sessions, and RMAN assigns eligible data files to available sessions as work becomes available. Each session reads Oracle blocks and writes an image copy using its configured destination format. When the RUN block completes, RMAN releases all three manual channels.

In the figure, the blue control path represents instructions from the RMAN client to the channel sessions. The teal backup data paths represent database blocks moving between the target CDB and the three disk destinations. The client coordinates the job, while the database-server sessions carry the backup data and create the image copies.

Parallel Channels and Multisection Backups

Multiple channels allow RMAN operations to run concurrently when enough work and system capacity are available. During an ordinary whole-CDB backup, RMAN can assign different data files to different channels. A channel can process multiple files over the life of the job, and the next available channel can receive the next eligible unit of work. The channel name does not permanently bind one source file to one destination.

Effective parallelism is bounded by more than the configured channel count. Source storage must supply blocks quickly enough, the database host must have CPU and memory for the server sessions, and the destination must accept concurrent writes. Network bandwidth and SBT media-manager or cloud-service limits can also constrain a job. More channels can reduce elapsed time on a capable system, but excessive channels may compete for the same resources and make the operation slower.

Select a channel count that reflects the number and performance of storage devices or service streams that can operate concurrently. Measure completed jobs under representative load and adjust the configuration based on observed throughput and contention. A test on one environment should not be treated as a universal recommendation for another database or storage design.

Without a multisection backup, RMAN does not divide one data file among several channels. A single very large data file can therefore limit parallelism even when other channels are idle. The SECTION SIZE clause divides an eligible file into independently processed sections so multiple channels can work on it concurrently:

BACKUP SECTION SIZE 4G DATABASE;

Here, 4G is an example rather than a general recommendation. The useful section size depends on the data-file sizes, channel count, backup format, and destination capabilities. Multisection processing should be selected deliberately. A normal backup does not automatically split every data file across all available channels.

Current Channel Controls

Channel operands refine how a channel performs its work. These controls replace obsolete SET LIMIT CHANNEL examples found in older material. Some operands are valid only for particular devices or backup formats, so their effects should be understood before they are added to a persistent or job-level configuration.

The RATE operand is useful when a backup must avoid consuming all available read bandwidth. The following manual channel limits its read rate to an example value of 100 megabytes per second for one job:

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE 100M;
  BACKUP DATABASE;
}

MAXPIECESIZE applies to backup pieces, so it affects backup sets rather than the size of an image-copy file. PARMS and SEND values are specific to an SBT implementation and should not be copied between products unless their documentation confirms compatibility.

Input-file multiplexing is related to channel processing, but it is not the same as channel parallelism. FILESPERSET influences how RMAN groups input files into a backup set, and MAXOPENFILES limits how many input files one channel can have open. The number of allocated channels determines how many I/O streams are available to execute eligible work concurrently.

CDB and PDB Context

For a whole-database backup in Oracle AI Database 26ai, the protected target is normally a CDB. The command's scope can include the CDB root and its PDB data files. RMAN also supports PDB-scoped backup and recovery operations when their requirements are met. In either scope, channels remain database-server sessions that execute the selected work. An account used for administrative RMAN operations must have the required privilege, commonly the SYSBACKUP administrative privilege.

Automatic Versus Manual Channels

Configure channels for repeatable operations. Allocate channels manually only when a particular RUN block needs temporary settings. In either case, size parallelism according to the available work and the measured capacity of the complete I/O path.

In the next lesson, you will learn how RMAN tags identify and select related backup sets and image copies without changing their physical format.