Preparing Oracle AI Database 26ai for RMAN

Preparing to use Oracle Recovery Manager is not simply a matter of starting the rman client or copying a sample backup command. A useful backup strategy begins with the business result that recovery must deliver. The administrator must determine how much data the organization can lose, how quickly service must return, which containers and files must be protected, and which failures the design must survive.

Lesson 3 identified the RMAN client, target CDB, channels, control-file repository, optional recovery catalog, and DISK or SBT paths. This lesson turns that architecture into an operational plan. The goal is not merely to produce backup pieces. It is to create recoverable copies, preserve everything needed to use them, monitor the process, and demonstrate recovery within approved objectives.

Define the requirements before selecting a command, schedule, or destination:

• Recovery point objective (RPO): the maximum acceptable data loss, usually measured as a period of time.
• Recovery time objective (RTO): the maximum acceptable time for restoring the required service.
• Retention requirement: how far back recovery must remain possible and how long archival copies must be kept.
• Recovery scope: the complete CDB, selected PDBs, tablespaces, data files, tables, or a Data Guard environment.
• Failure domain: a storage, site, credential, or administrative boundary that could make production and its backups unavailable together.

These decisions affect archived-redo protection, backup frequency, level 0 and level 1 design, channel parallelism, retention, storage separation, catalog use, and recovery testing. A nightly backup cannot satisfy an eight-hour RPO if the redo needed after that backup is unavailable. Likewise, a valid backup does not satisfy a two-hour RTO when restoring and recovering it takes six hours.

RMAN protects Oracle physical database files. Depending on the command and connection scope, it can back up a whole database, PDBs, tablespaces, data files, the control file, the server parameter file (SPFILE), and archived redo logs. Data files can be stored in backup sets or as image copies. RMAN can also back up existing RMAN copies in supported workflows.

RMAN does not back up every file needed to rebuild a database service. Oracle's 26ai Reference excludes network configuration files, password files, the block change tracking file, and Oracle home contents. External-table files and data referenced through BFILE are also outside the physical database-file backup boundary.

The recovery plan must therefore protect or reproducibly recreate password files, Oracle Net configuration, text initialization files when used, TDE keystores and credentials, destination configuration, external application files, scripts, and the required Oracle software and patches. Runbooks and access procedures are recovery dependencies too. A database backup is incomplete operationally when the team cannot authenticate, open the keystore, reach the media, or reconstruct the software environment.

Oracle AI Database 26ai uses the multitenant architecture, so each job must have a documented scope. Whole-CDB and multi-PDB work uses a target connection to the CDB root as a common user with SYSBACKUP or SYSDBA. A supported single-PDB operation can use a common or local administrative user, subject to the operation's restrictions.

A PDB connection is not equivalent to a root connection. Archived redo belongs to the CDB. A backup that includes archived redo, including BACKUP DATABASE PLUS ARCHIVELOG, requires the appropriate root connection. The plan should also identify whether PDB restore, point-in-time recovery, table recovery, duplication, or a physical standby must be tested rather than assuming that a whole-CDB backup proves every narrower workflow.

Archiving mode determines when RMAN can back up the database and which recovery points are possible. Verify the current mode rather than relying on an installation record:

SELECT log_mode
FROM   v$database;

In ARCHIVELOG mode, RMAN can back up the database while it is open. An online backup is inconsistent until recovery applies the required redo, so archived-log availability is part of the backup strategy. The team must plan archive destinations, capacity, monitoring, backup frequency, and deletion. In a Data Guard environment, the plan must also account for redo transport and apply requirements.

In NOARCHIVELOG mode, a valid whole-database backup requires the database to be mounted after a consistent shutdown. The database cannot use the normal open-backup and point-in-time-recovery model. Changing a production database to ARCHIVELOG requires an approved procedure; it should not be presented as an isolated toggle without capacity and operational planning.

Connections to a target or auxiliary database require SYSBACKUP or SYSDBA. Use a named backup operator granted SYSBACKUP for routine administration instead of teaching routine use of SYS or the default SYSBACKUP account. Starting with Oracle AI Database 26ai, dictionary protection applies to the SYSBACKUP administrative privilege.

Local operating-system authentication and remote password-file authentication have different prerequisites. A remote Oracle Net connection requires a working service and password file. Let RMAN prompt for the password:

$ rman
RMAN> CONNECT TARGET "backup_operator@cdbprod AS SYSBACKUP";

Never embed database passwords, backup-encryption passwords, wallet secrets, or cloud credentials in shell commands, command files, screenshots, logs, or source control. Test how authorized responders will obtain credentials during an outage, including a failure of the normal identity or secrets service.

CONFIGURE settings persist in the target's RMAN repository until they are changed or cleared. Before applying a template, capture the current state and compare it with the approved design:

RMAN> SHOW ALL;
RMAN> SHOW DEFAULT DEVICE TYPE;
RMAN> SHOW RETENTION POLICY;
RMAN> SHOW CONTROLFILE AUTOBACKUP;
RMAN> SHOW ARCHIVELOG DELETION POLICY;
RMAN> SHOW ENCRYPTION;

Review automatic channels, device parallelism, formats, backup types, compression, encryption, control-file autobackup, retention, and archived-log deletion. In Data Guard, include configuration associated with each DB_UNIQUE_NAME. The output is a baseline for review; its defaults do not prove that the destination, recovery window, or security controls are suitable.

DISK is RMAN's preconfigured device type. A disk destination can be a server-visible filesystem, ASM disk group, or Fast Recovery Area (FRA). If an FRA is configured and no disk format is specified, RMAN can create Oracle-managed backup names there. Verify that every instance which may allocate a channel can reach the destination with the required permissions and throughput.

The FRA is finite shared recovery space. Backups, archived redo, flashback logs, and other files can compete for its capacity. Size it from measured generation and retention needs, monitor its usage, and understand which files can become reclaimable. The FRA does not automatically create an independent or offsite copy, especially when it shares storage or administration with production.

An SBT channel calls compatible media-management software or an Oracle native SBT library. Tape, Recovery Appliance, and supported cloud destinations require their documented integration, credentials, network path, and media policies. RMAN does not write to an arbitrary object-storage bucket without such an integration. Allocate a test channel and perform a backup-and-restore test before depending on a new SBT destination.

Oracle Secure Backup can provide an SBT tape interface during its supported lifecycle, but Oracle announced OSB 19.1 desupport on May 1, 2026, with Premier Support ending September 30, 2027. A new design should verify current support and select an appropriate supported media manager or Oracle protection service. Managed and Autonomous services can impose different responsibility boundaries, so their current service documentation controls.

The target control file always contains RMAN repository records. Without a recovery catalog, it is the exclusive repository for backup metadata and persistent configuration. Multiplexing control files across separate storage reduces exposure to one failed copy, but multiplexing is not a backup.

Enable control-file autobackup with CONFIGURE CONTROLFILE AUTOBACKUP ON unless the applicable managed service supplies an equivalent documented policy.

An autobackup can make it possible to restore the control file when the current repository and catalog are unavailable. When the instance was started with an SPFILE, the autobackup can include it. Record the database identifier, destination, device configuration, and autobackup format needed to locate it, and test the procedure without depending on the current control file.

CONTROL_FILE_RECORD_KEEP_TIME specifies the minimum age before reusable control-file records become candidates for reuse. Its default does not guarantee a fixed number of days of complete operational history. A database without a catalog should set and monitor it in relation to backup frequency and retention, recognizing that record pressure and control-file growth also matter.

A recovery catalog is not required for every RMAN environment. It is an Oracle schema containing synchronized RMAN metadata, not a location for backup pieces. It can preserve longer history, centralize reporting for multiple targets, and store RMAN scripts. The catalog database, schema, credentials, and its own recovery procedure must also be protected.

Tablespace point-in-time recovery does not generally require a catalog, and loss of the current control file does not make a catalog mandatory when a usable autobackup and the required identifiers are available. If a catalog is created, do not place it in SYS or SYSBACKUP. Starting with 26ai, RMAN automatically disconnects from the catalog before a target-database backup operation; the catalog is not in the backup data path.

An RMAN retention policy identifies which backups are needed to meet a recovery objective. A recovery window expresses how far backward in time recovery must remain possible. A redundancy policy retains a specified number of full or level 0 backups for each data file under RMAN's rules. For example:

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
RMAN> REPORT OBSOLETE;

The value is only an example; it must come from the approved requirement. A retention policy marks backups OBSOLETE. It does not create backups, guarantee required redo, or mean that every obsolete file is automatically deleted. DELETE OBSOLETE is a destructive maintenance operation and should run only after retention, replicas, legal holds, and destination behavior have been verified.

An archived-log deletion policy answers a different question: when archived redo becomes eligible for deletion. Before configuring it, identify required backup copies and device types, Data Guard shipping and apply requirements, downstream consumers, destination outages, and alternate accessible copies. Do not use aggressive deletion or DELETE INPUT merely to control space; losing required redo can defeat an otherwise valid backup strategy.

Use precise RMAN terminology. A full data-file backup contains all used blocks but is not an incremental baseline. A level 0 incremental also backs up all used blocks and establishes the base for level 1 backups. A differential level 1 contains blocks changed since the most recent level 0 or level 1. A cumulative level 1 contains blocks changed since the most recent level 0. Block Change Tracking can reduce scanning during incrementals.

Select the pattern by measuring the backup window, change rate, storage use, and restore work needed to meet the RTO. A “full database backup” is not by itself complete disaster protection; recovery can still depend on archived redo, repository metadata, credentials, encryption material, and non-RMAN configuration.

Compression, encryption, channel parallelism, and backup optimization are design choices rather than universal improvements. Compression trades CPU for space and may have licensing conditions. RMAN backup encryption applies to backup sets, not image copies. Transparent, password-based, and dual-mode encryption have different recovery dependencies; separately protect and test the required keystore or password.

Additional channels help only when the database edition, storage, media, CPU, memory, and network can sustain them. Backup optimization can skip certain identical files already backed up to the same device type, but it is not an incremental backup and does not replace retention. Test each setting with the actual production-scale path rather than relying on a generic recommendation.

RMAN checks Oracle blocks while backing them up, and VALIDATE or BACKUP VALIDATE can examine files without producing a backup. RESTORE ... PREVIEW reports which backups RMAN expects to use, while RESTORE ... VALIDATE reads the required backup data without restoring production files. These checks increase confidence, but none proves that the complete service can meet its RTO.

Schedule isolated restore-and-recovery drills. A drill should obtain credentials through the emergency process, reach the actual media, restore the required control file or catalog metadata, open the keystore, restore and recover the selected scope, and verify database and application behavior. Record elapsed time, missing dependencies, manual steps, and corrective actions.

Monitor RMAN job status, duration, throughput, backup age, archived-redo protection, FRA or filesystem capacity, control-file autobackups, repository state, media-manager results, corruption findings, and the date of the last successful recovery drill. CROSSCHECK reconciles repository records with accessible media; it does not validate backup contents.

Do not use the Data Recovery Advisor workflow in Oracle AI Database 26ai. The commands LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE are desupported, and Oracle states that there is no replacement. Use supported RMAN validation, restore, recovery, monitoring, and tested operational procedures without presenting them as a renamed advisor.

• RPO, RTO, retention, protected scope, and recovery priority are approved.
• The CDB or PDB connection scope and ARCHIVELOG consequences are documented.
• A named SYSBACKUP operator and emergency authentication path have been tested.
• Persistent RMAN configuration has been reviewed rather than accepted as an unexplained default.
• Disk, FRA, SBT, and network paths have adequate capacity, throughput, monitoring, and failure separation.
• Control-file autobackup is enabled and recoverable; the catalog decision matches the topology.
• Retention and archived-log deletion policies preserve every required recovery and standby path.
• Password files, keystores, Oracle Net files, external data, software configuration, and runbooks are protected separately.
• Backup validation and a successful isolated recovery drill provide current evidence that the strategy works.

Preparation is complete only when the organization can explain what will be recovered, from which media, by whom, and within what time. The next lesson can then build on this approved baseline instead of treating a backup command as the recovery strategy.

• Oracle AI Database Backup and Recovery User's Guide, 26ai
• Oracle AI Database Backup and Recovery Reference, 26ai