Lesson 2	Understanding backup sets
Objective	Review the structure and purpose of an RMAN backup set.

Using RMAN Backup Sets in Oracle AI Database 26ai

Recovery Manager (RMAN) can create two principal physical backup formats: backup sets and image copies. Both formats can protect an Oracle database, but they organize backup data differently and support different storage and recovery strategies.

An RMAN image copy has the same logical structure as the data file, archived redo log, or control file from which it was created. A backup set, by contrast, is an RMAN-specific logical container. RMAN stores its contents in one or more physical backup pieces and must interpret those pieces during a restore. This lesson reviews the backup-set model and explains why RMAN's integration with Oracle Database is important.

Distinguishing Three Backup Concepts

The original version of this lesson treated an image copy and a file copied from an operating-system prompt as if they were the same operation. The resulting files can be physically similar, but their creation and management are different. A current recovery plan should distinguish among three concepts:

RMAN image copy: RMAN creates a disk copy with BACKUP AS COPY and records its metadata in the RMAN repository.
User-managed backup: An administrator, storage system, or third-party utility copies a database file outside RMAN. RMAN does not automatically know that the copy exists.
RMAN backup set: RMAN reads Oracle blocks, organizes the selected data into a logical backup set, and writes one or more backup pieces.

When RMAN creates an image copy, it coordinates the operation with the database and records the source file, checkpoint, system change number (SCN), completion time, status, and physical location. For example:

BACKUP AS COPY DATAFILE 7;

RMAN can then list, catalog, crosscheck, validate, switch to, restore, or recover the copy as appropriate. An RMAN image copy can be created while the database is open without placing its data files in user-managed backup mode.

An operating-system or storage-level copy is a user-managed backup. RMAN does not know it exists until a compatible copy is registered with CATALOG. Cataloging records metadata; it does not repair or validate the copy.

Why RMAN Is the Preferred Backup Method

RMAN communicates with the Oracle database while it reads database blocks. This block-aware integration allows RMAN to create a consistent online backup without surrounding the operation with user-managed BEGIN BACKUP and END BACKUP commands. RMAN also records the information required to locate and evaluate the backup during restore and recovery.

A simple OS copy command does not provide the following RMAN capabilities by itself:

Coordination with an open Oracle database during backup.
Awareness of data-file headers, checkpoints, SCNs, and archived redo requirements.
Automatic repository records for backup sets, backup pieces, and image copies.
Full and incremental backups, including incrementally updated image-copy strategies.
Block checking during backup and separate backup-validation operations.
Binary compression, encryption, backup-set duplexing, and SBT integration.
Retention-policy reporting, crosschecks, obsolete-backup identification, and restore preview.
CDB-level and PDB-aware backup and recovery in the multitenant architecture.

RMAN does not eliminate the need for a recovery design. Administrators must still protect the repository, archived redo logs, control file, SPFILE, and encryption keys, keep backup pieces accessible, and test the recovery procedure.

When User-Managed Backup Mode Is Relevant

Oracle AI Database 26ai still supports user-managed online backups. The technique is relevant when an external storage snapshot or file-copy utility must capture an online data file without using RMAN's block-aware read process. Depending on the scope and storage procedure, the documented workflow may require the database, PDB, or tablespace to be placed in backup mode before the external copy begins.

A database-level user-managed workflow can begin backup mode with:

ALTER DATABASE BEGIN BACKUP;

The administrator or storage system then creates the required copy or snapshot. After every required operation has completed successfully, backup mode must be ended promptly:

ALTER DATABASE END BACKUP;

Backup mode does not make the database read-only and does not stop Oracle from writing to its data files. An external copy can read part of an Oracle block before a database write and another part after that write, producing a split or fractured block in the copy. While backup mode is active, Oracle generates the additional redo information required to reconstruct affected blocks during recovery. Leaving files in backup mode longer than necessary can therefore increase redo generation and operational risk.

A consistent offline user-managed copy can instead be made after a clean database shutdown or, where supported, after taking the relevant tablespace offline. The exact method depends on whether the operation protects a container database (CDB), a pluggable database (PDB), or selected tablespaces and data files. Any production implementation should follow current Oracle 26ai documentation and the storage vendor's validated snapshot procedure.

This lesson no longer provides generic Linux cp or Windows copy commands. The command that copies a file is the simplest part of the process. Consistency, metadata, archived redo, encryption keys, destination durability, and a tested recovery procedure determine whether the copy is a usable backup.

Backup Sets and Backup Pieces

A backup set is the smallest logical unit of an RMAN backup. It contains the backup data selected from one or more input files. RMAN records each set in the target control-file repository and, when the environment uses one, in the recovery catalog.

A backup piece is the physical output written by an RMAN channel. A backup set contains one or more backup pieces. On disk, a backup piece appears as a file with an RMAN-specific format. Through a System Backup to Tape (SBT) channel, the media-management or supported cloud library stores the piece as an object that it manages through the SBT interface.

Relationship among RMAN backup objects
Object	Role	Management
Input file	Supplies data-file blocks, control-file data, SPFILE data, or archived redo	Oracle Database and RMAN
Backup set	Logical RMAN unit that groups selected backup data	RMAN repository
Backup piece	Physical file or media object containing backup-set data	RMAN channel and destination
Repository record	Connects the backup to files, checkpoints, pieces, status, and location	Target control file and optional recovery catalog

The creation sequence is straightforward:

RMAN selects data files, archived redo logs, or other supported input.
One or more RMAN channels read the required blocks.
RMAN organizes the selected data into a logical backup set.
Each channel writes the backup set as one or more backup pieces.
RMAN records metadata connecting the source files, backup set, pieces, checkpoints, status, and destination.

During restore, RMAN queries this metadata to select usable backups, locates the required pieces, and reconstructs the requested database files. A backup piece is not a byte-for-byte data-file copy that an administrator can place directly in the database directory. RMAN must read and interpret it.

Data-File and Archived-Log Backup Sets

RMAN separates data-file content from archived redo-log content. A data-file backup set can contain full or incremental data-file backups and can include a control-file or server-parameter-file backup when allowed by the command. Archived redo logs are stored in archived-log backup sets rather than mixed into the same backup set as data files.

This distinction reflects their recovery roles. A restored data file provides a starting point. Archived and online redo then apply the changes required to recover that file to the desired SCN, time, or log sequence. RMAN uses repository records and data-file headers to determine which backup and redo are needed for the requested recovery.

A backup set can span multiple pieces, and all required pieces must remain available. Backup duplexing, replicated media, and off-site copies can reduce the risk of losing a required piece.

Unused Blocks Are Not Binary Compression

RMAN understands Oracle data-file blocks. When applicable, a data-file backup set can omit blocks that do not need to be backed up, including eligible blocks that have never been used. Oracle documentation describes this behavior as unused-block compression or precompression block processing. It reduces the amount of input written to the backup piece without running a general binary compression algorithm over every byte.

Optional binary compression is a separate backup-set feature. It can be requested for a single backup with:

BACKUP AS COMPRESSED BACKUPSET DATABASE;

Binary compression encodes the selected backup data before RMAN writes it. Its effectiveness depends on the source data, encryption state, selected algorithm, and available CPU capacity. Data that is already compressed or encrypted may provide less additional reduction. Administrators should compare backup duration, CPU use, backup size, and restore speed with representative workloads.

The correct conceptual distinction is:

Block-selection optimizations can reduce how much source data enters the backup set.
Binary compression can further reduce how RMAN represents that selected data in the backup pieces.

Channels, Multiplexing, and Parallelism

An RMAN channel represents a stream of work between RMAN and a storage device. A disk channel writes pieces to disk, while an SBT channel passes pieces to a media-management or supported cloud library. Multiple channels can create different backup sets or sections concurrently when the source system and destination can sustain the additional workload.

RMAN can multiplex blocks from multiple input files into a backup piece. Multiplexing helps keep an output device busy when one input file cannot supply data quickly enough. Multisection backup addresses a different problem by dividing a large data file into independently processed sections. Later lessons explain how channel parallelism, multiplexing, FILESPERSET, MAXOPENFILES, and section size affect backup and restore throughput.

More channels do not guarantee a proportionally faster backup. Tune parallelism with measured backup and restore performance across the complete storage path.

Backup Sets in the Multitenant Architecture

Oracle AI Database 26ai uses the multitenant architecture. RMAN can create backups for an entire CDB, selected PDBs, tablespaces, or data files, subject to the connection context and command. Backup-set metadata retains the identity and recovery information needed to associate protected files with their containers.

A complete strategy also protects the control file, SPFILE, archived redo logs, RMAN repository, and any encryption keystore. Intact backup pieces cannot be recovered when a required encryption key is unavailable.

Reviewing Backup Sets in RMAN

Administrators should inspect backup sets through RMAN rather than attempting to open backup pieces with operating-system tools. The following commands show a compact inventory and more detailed information about database backups:

LIST BACKUP SUMMARY;
LIST BACKUP OF DATABASE;

The detailed output identifies logical backup sets and their associated pieces. A repository record, however, does not prove that every piece is still readable or accessible. Files can be deleted outside RMAN, SBT credentials can expire, cloud policies can change, and encryption keys can become unavailable.

Use crosschecks and validation during routine maintenance, then perform periodic restore and recovery tests. A test exercises repository access, media libraries, credentials, encryption keys, network routes, capacity, and the operator procedure.

Backup-Set Concept Review

A backup set is a logical RMAN backup, not an ordinary operating-system file.
A backup set contains one or more physical backup pieces written by an RMAN channel.
RMAN image copies and user-managed OS copies can be physically similar, but only RMAN-managed or cataloged copies appear in the RMAN repository.
Ordinary RMAN backups do not require user-managed BEGIN BACKUP and END BACKUP commands.
User-managed online-copy and storage-snapshot workflows remain supported, but require careful consistency and recovery planning.
Unused-block optimization and optional binary compression are separate mechanisms.
Repository inspection, validation, and restore testing are all necessary parts of backup management.

Backup sets remain a core RMAN format in Oracle AI Database 26ai. Their value comes from RMAN's ability to understand Oracle blocks, coordinate online backup activity, store recovery metadata, and manage the pieces required to restore protected files.

In the next lesson, you will examine the BACKUP command syntax used to create backup sets.