Lesson 8

In this module, you learned how Oracle Recovery Manager (RMAN) creates and manages backup sets in Oracle AI Database 26ai. A backup set is an RMAN-specific logical backup that contains one or more physical backup pieces. Those pieces can hold backed-up blocks from data files, control files, the server parameter file, or archived redo logs.

Backup sets provide capabilities that ordinary operating-system copies do not provide. RMAN can omit blocks that have never been used, multiplex blocks from several input files, apply binary compression, encrypt backup contents, divide large data files into sections, and send backup pieces through disk or media-management channels. Because the output uses an RMAN-specific format, RMAN must restore the files before the database can use them.

The most important lesson is that creating a backup file is only one part of protecting a database. A usable strategy must also preserve the metadata, archived redo logs, credentials, encryption keys, storage paths, and operating procedures needed to restore and recover the database. Regular validation and restore testing turn backup files into evidence that the recovery plan works.

After completing this module, you should be able to:

1. Explain the relationship among backup sets, backup pieces, input files, and RMAN channels.
2. Recognize the main clauses of the RMAN BACKUP command and construct a practical backup specification.
3. Explain how FILESPERSET and MAXOPENFILES control file grouping and backup-set multiplexing.
4. Describe how channels and multisection backups provide different forms of parallel execution.
5. Identify full and incremental data file backup sets in RMAN output and repository views.
6. Identify archived redo log backup sets and explain why they are essential to media recovery.
7. Apply crosschecks, validation, retention maintenance, and restore tests to manage backup sets throughout their lifecycle.

RMAN distinguishes the logical backup from the files written to a backup destination. A backup set is the logical unit recorded in the RMAN repository. A backup piece is a physical binary file, tape object, or media-manager object that belongs to the set. Most ordinary backup sets contain one piece, but a set can contain additional pieces when a piece-size limit is reached or when a multisection backup divides one large file among several channels.

A data file backup set contains full or incremental data file backups and can also include a control file or server parameter file. An archived redo log backup set contains archived redo logs. RMAN does not mix data files and archived redo logs in the same backup set, even when one BACKUP command creates both types.

Backup object	Characteristics	Typical use
Backup set	Logical RMAN unit containing one or more backup pieces	Disk, tape, media-manager, compressed, or encrypted backups
Backup piece	Physical RMAN-formatted output belonging to one backup set	The file or media object read during an RMAN restore
Image copy	Bit-for-bit copy with the same file layout as the source file	Disk-based recovery strategies that can switch to a copy

Image copies are never multiplexed, and RMAN binary compression applies to backup sets rather than image copies. An image copy can sometimes be used directly by switching the database to the copy. A backup piece cannot be treated as a data file because RMAN must first extract the required blocks during a restore.

The BACKUP command identifies the output format, the objects to protect, and the options that control grouping, selection, and performance. RMAN can use persistent channel settings established with CONFIGURE, or channels can be allocated temporarily inside a RUN block.

RUN {
  ALLOCATE CHANNEL c1 DEVICE TYPE DISK
    FORMAT '/backup/rman/%d_%T_%U.bkp';
  ALLOCATE CHANNEL c2 DEVICE TYPE DISK
    FORMAT '/backup/rman/%d_%T_%U.bkp';

  BACKUP AS COMPRESSED BACKUPSET
    DATABASE
    FILESPERSET 4
    PLUS ARCHIVELOG;
}

This example allocates two disk channels, creates compressed backup sets for the database, limits each data file set to four input files, and also creates the archived redo log backup sets needed to recover the data file backup. The exact number of sets and pieces depends on the input files, channel configuration, file grouping, sectioning, and size limits.

The FORMAT clause supplies a formatspec, which is a filename template containing substitution variables. In the example, %d represents the database name, %T represents the date, and %U produces a system-generated unique name. Other commonly encountered variables include %s for the backup-set number and %p for the piece number within the set.

Using %U is generally safer than constructing a name from variables that might not be unique across all pieces and backup jobs. The destination must also have adequate capacity, correct permissions, and a retention process that prevents active backups from being removed prematurely.

Backup-set multiplexing occurs when one RMAN channel reads blocks from multiple input files and writes those blocks into the same backup piece. Multiplexing can keep an output stream busy when a single source file cannot supply data fast enough, but excessive multiplexing can reduce the sequential nature of I/O and make some restores less efficient.

Two settings work together:

• FILESPERSET limits the number of input files that RMAN can place in one backup set.
• MAXOPENFILES limits the number of input files that one channel can keep open and read concurrently.

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. For example, if FILESPERSET is 4 and MAXOPENFILES is 8, a set containing four data files can have a multiplexing level of four. Setting FILESPERSET 1 prevents blocks from different input files from being placed in the same set.

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

A smaller FILESPERSET value can create more backup sets and expose more independent work to parallel channels. It can also create more output files and repository records. Select values by measuring both backup and restore performance rather than assuming that the highest multiplexing level or the greatest number of sets is always best.

An RMAN channel represents one server session and one stream of data to or from a backup device. Configuring several channels lets RMAN assign separate backup sets to separate sessions. The channel count establishes the maximum potential parallelism, but the backup job must contain enough independent work to keep those channels active.

CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO BACKUPSET;

Four channels do not guarantee that a job will run four times faster. Disk throughput, ASM capacity, CPU, network bandwidth, tape drives, cloud or media-manager limits, and competition from database workloads can become bottlenecks. Parallelism should be increased only while measured backup and restore performance continues to improve.

Mechanism	Work performed	Result
Channel parallelism	Separate backup sets run through separate server sessions	Multiple sets can be active concurrently
Multiplexing	One channel reads blocks from several input files	Interleaved blocks are written into one piece
Multisection backup	Several channels back up sections of one large file	One set contains independently produced section pieces

A multisection backup is the important exception to the ordinary one-channel-per-piece model. The SECTION SIZE clause divides one large data file into contiguous block ranges. Different channels can write different section pieces concurrently, while all completed pieces remain part of the same backup set.

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

Use multisection backups when one very large data file would otherwise keep one channel busy after the remaining channels become idle. SECTION SIZE cannot be combined with MAXPIECESIZE in the same backup. Multisection behavior should also be tested during restore because recovery time, not only backup time, determines whether the configuration meets operational requirements.

The simplest way to identify a data file backup set is to use RMAN LIST commands. Detailed output identifies the backup-set key, backup type, completion time, pieces, and data files included in each set.

LIST BACKUP OF DATABASE;
LIST BACKUP OF DATAFILE 1;
LIST BACKUP OF TABLESPACE USERS;
LIST BACKUP BY FILE;
LIST BACKUP SUMMARY;

For automated reporting, query the repository stored in the target database control file. In V$BACKUP_SET, a BACKUP_TYPE of D identifies a full data file backup, I identifies an incremental data file backup, and L identifies an archived redo log backup. Incremental levels 0 and 1 are reported in INCREMENTAL_LEVEL.

SELECT set_stamp,
       set_count,
       backup_type,
       incremental_level,
       pieces,
       multi_section,
       completion_time
FROM   v$backup_set
ORDER BY completion_time DESC;

SET_STAMP and SET_COUNT together identify a control-file repository backup set and join it to V$BACKUP_DATAFILE, V$BACKUP_PIECE, and related views. When a recovery catalog is used, views such as RC_BACKUP_SET, RC_BACKUP_DATAFILE, and RC_BACKUP_PIECE provide a longer history and support reporting across registered databases.

A multisection data file backup is identified by MULTI_SECTION = 'YES'. Multiple piece or section records do not mean that separate complete copies of the data file exist. RMAN coordinates the pieces as sections of one complete backup.

Archived redo logs preserve database changes generated while data file backups are being created and after those backups finish. During media recovery, RMAN restores a suitable data file backup and applies redo to move the file toward the required recovery point. A backup plan that protects data files but fails to preserve the required redo may not meet its recovery-point objective.

LIST BACKUP OF ARCHIVELOG ALL;
LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 1000 UNTIL SEQUENCE 1100;

In detailed RMAN output, an archived redo log set contains a list of archived logs with thread and sequence information. In V$BACKUP_SET or RC_BACKUP_SET, BACKUP_TYPE = 'L' identifies the set. Control-file views such as V$BACKUP_REDOLOG and recovery-catalog views such as RC_BACKUP_REDOLOG identify the logs belonging to the set.

FILESPERSET also controls archived redo log grouping. With three channels, five archived logs, and FILESPERSET 2, RMAN can create sets containing two, two, and one log. All three sets can run concurrently. Nine logs require five sets, so only three begin immediately and channels receive the remaining sets as earlier work completes.

BACKUP ARCHIVELOG ALL FILESPERSET 2;

The DELETE INPUT and DELETE ALL INPUT clauses can remove archived redo logs after successful backup, but they must be used with a deliberate archived-log deletion policy. In a Data Guard environment, the policy must account for whether required logs have been shipped or applied to the appropriate standby databases. Reclaiming archive-destination space must not take priority over recoverability.

RMAN records backup metadata in the target database control file and, when configured, in a recovery catalog. The control file is therefore part of the recovery chain. Enabling control-file autobackups gives RMAN an independent copy of the control file and server parameter file after backups and important structural changes.

CONFIGURE CONTROLFILE AUTOBACKUP ON;

A recovery catalog is optional, but it preserves metadata beyond the control file's reusable record window and supports centralized reporting, stored scripts, and longer backup histories. Whether or not a catalog is used, document the database identifier, autobackup location, media library configuration, encryption-key procedure, and credentials required for disaster recovery.

When backing up an entire container database, connect to the CDB root with an appropriately privileged common account, preferably one granted SYSBACKUP. Apply least privilege, avoid embedding clear-text passwords in command files, protect wallet and keystore material, and restrict access to backup destinations. A backup that cannot be decrypted during a disaster is not a usable recovery asset.

RMAN repository status must agree with the storage system. A crosscheck examines whether recorded backup pieces are still present and updates missing pieces to EXPIRED. Expired means that RMAN cannot find the object at its recorded location. Obsolete has a different meaning: the backup is no longer required to satisfy the configured retention policy.

CROSSCHECK BACKUP;
DELETE EXPIRED BACKUP;
REPORT OBSOLETE;
DELETE OBSOLETE;

Run deletion commands only after reviewing the retention policy and the reported objects. A recovery window or redundancy policy expresses the minimum recovery coverage RMAN must retain, but business requirements may also require offsite copies, legal retention, immutable storage, or additional generations that are not represented by one RMAN policy.

Validation checks readability and block integrity without performing a production restore. BACKUP VALIDATE reads the source files as a backup would but creates no backup set. RESTORE ... VALIDATE checks whether RMAN can read the backup pieces required for a restore. An individual set can also be validated by its backup-set key.

BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
RESTORE DATABASE VALIDATE;
VALIDATE BACKUPSET 123;

Validation is necessary, but it is not a substitute for a restore and recovery test. Periodically restore backups to an isolated environment, recover them to a defined point, open or otherwise verify the recovered database as appropriate, and record the elapsed time. This test exposes problems involving capacity, credentials, encryption keys, network paths, tape or object-storage access, archived redo availability, and the accuracy of the recovery procedure.

1. Define recovery objectives. Establish the required recovery point, recovery time, retention period, and offsite protection.
2. Select backup contents. Protect the database, archived redo logs, control file, server parameter file, and required metadata.
3. Configure destinations and channels. Match parallelism to the throughput that disk, network, or media infrastructure can sustain.
4. Control grouping. Use FILESPERSET, MAXOPENFILES, size limits, and SECTION SIZE for specific needs.
5. Create uniquely named output. Use a safe FORMAT specification and monitor destination capacity.
6. Review RMAN output. Confirm that expected data files, archived redo logs, pieces, and autobackups completed successfully.
7. Maintain repository accuracy. Crosscheck recorded backups and distinguish expired objects from retention-policy obsolete objects.
8. Validate and restore-test. Prove that required backup pieces and redo can produce a usable database within the recovery objectives.
9. Measure and tune. Adjust channels, multiplexing, section sizes, compression, and storage paths using observed backup and restore results.

Backup sets are the foundation of many RMAN strategies because they combine efficient storage with flexible file selection, compression, encryption, media-manager support, and parallel processing. Backup pieces are the physical output, while channels are the server sessions that create or read that output. Keeping these concepts separate makes RMAN command behavior and repository reports much easier to interpret.

FILESPERSET controls how input files are grouped, and MAXOPENFILES limits how many files one channel reads concurrently. Multiple channels create independent backup sets in parallel, while SECTION SIZE lets several channels contribute to one large data file backup. Data file sets and archived redo log sets can be identified with RMAN LIST commands or through control-file and recovery- catalog views.

A sound strategy does not end when RMAN reports that a backup completed. Protect the repository, control-file autobackups, archived redo logs, credentials, and encryption keys. Keep repository metadata synchronized with physical storage, remove backups according to an intentional retention policy, and perform realistic restore and recovery tests. Those practices determine whether backup sets can satisfy the organization's recovery requirements when a failure occurs.

The term formatspec was introduced in this module. A formatspec is a template used by the RMAN FORMAT clause to name backup pieces or image copies. It can be specified for a BACKUP command, an individual backup specification, or a channel, depending on the required destination and naming policy.

In the next module, you will learn advanced techniques for using Recovery Manager.

Use the matching exercise to test your understanding of backup sets, backup pieces, channels, file grouping, data file backups, archived redo log backups, the SKIP clause, and FORMAT specifications.
Backup Set - Exercise