Online and Offline RMAN Backups in Oracle 26ai

Oracle AI Database 26ai supports backups while a target database is open and while it is closed or mounted. These operating conditions are commonly called online and offline backups. They answer a different question from backup consistency. Online or offline describes whether the database, pluggable database (PDB), tablespace, or data file remains available while files are copied. Consistent or inconsistent describes whether the backed-up files are synchronized to a common checkpoint and whether media recovery must apply redo after restoration.

This distinction is central to a reliable recovery plan. An open RMAN whole-database backup is an inconsistent backup, but it is recoverable when the required archived redo logs are available. A mounted whole-database backup is consistent only if the database was shut down cleanly before it was mounted. A database operating in NOARCHIVELOG mode requires a consistent closed RMAN backup.

The informal terms hot backup and cold backup usually mean online and offline backup. The more precise terms are preferable when discussing recovery. Also, a full backup is not another name for a closed or consistent backup. In RMAN, full describes the blocks selected from an object; it does not describe database availability or consistency.

Online RMAN Backups in ARCHIVELOG Mode

An RMAN whole-database backup can run while the target container database (CDB) is open when the database operates in ARCHIVELOG mode. Applications can continue using the database while RMAN channels read its files. Because database writer (DBWR) processes can continue changing data blocks and advancing checkpoints during the operation, the files in the backup do not all represent one instant. The backup is intentionally inconsistent.

Archived redo provides the changes needed to make restored files consistent. A common introductory command is:

BACKUP DATABASE PLUS ARCHIVELOG;

This command backs up the eligible database files and archived redo logs to the configured device and in the configured backup format. The PLUS ARCHIVELOG option also causes RMAN to archive the current online redo at documented points in the operation and include the newly archived logs. This helps protect the redo surrounding the database backup.

The option does not guarantee unlimited retention. Archived logs can later be removed by RMAN retention and deletion policies, administrator commands, Fast Recovery Area space management, or external storage operations. A usable online-backup strategy must preserve the archived redo required by the recovery window, monitor every destination, and verify that the logs can be restored.

After an online backup is restored, RMAN applies redo during media recovery so the restored data files reach a mutually consistent point. The database can then be opened according to the recovery operation being performed. The fact that the backup completed successfully does not by itself prove that all required backup pieces, image copies, control-file information, archived logs, credentials, and encryption material will be available during a failure.

Why RMAN Does Not Use Backup Mode

An RMAN-created online backup does not require ALTER TABLESPACE ... BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP. The reason is not merely that RMAN is an Oracle utility. Each RMAN channel is a database-server session that understands the Oracle block format and the order in which it reads blocks.

An external copy program can read a block while DBWR is changing it. The beginning of the copied block can then represent a different moment from its end. Oracle calls this condition a fractured block. The block is not consistent with one system change number (SCN). An SCN is Oracle's logical ordering value for database changes and checkpoints. RMAN and media recovery use SCNs to determine which redo must be applied and when recovery can stop.

During an RMAN backup, the channel's server session compares the block header and footer. If the block appears fractured, the session rereads it. A transient fracture can disappear after the concurrent update finishes. If the documented reread still finds the same fracture, RMAN treats the block as corrupt. RMAN also knows its block-read order and can capture a usable data-file checkpoint without freezing the data-file header checkpoint. These database-aware safeguards remove the need for user-managed backup mode during an RMAN backup.

User-Managed Online Backups

Backup mode applies when an operating-system command, storage utility, or other external mechanism copies online Oracle data files without independently providing Oracle's required consistency safeguards. It changes Oracle's behavior while the external tool performs the copy; it does not create the backup itself.

For a user-managed copy of an online tablespace, the essential sequence is:

ALTER TABLESPACE users BEGIN BACKUP;
-- Copy the USERS data files with the approved external tool.
ALTER TABLESPACE users END BACKUP;

The administrator must identify the correct files, place the tablespace in backup mode immediately before copying, perform the external copy, and end backup mode immediately afterward. The procedure must also protect the required archived redo and control-file information. The V$BACKUP view can be checked to ensure that no data file was unintentionally left in active backup mode.

Backup mode can increase redo generation because Oracle records the full before-image of a changed block as needed to protect recovery from a fractured external copy. Leaving files in backup mode longer than necessary increases redo volume and operational risk. A user-managed copy should later be cataloged when RMAN must manage it, but cataloging does not validate every block or prove that all files and redo needed for recovery are present.

Storage Snapshots in Oracle 26ai

Oracle 26ai desupports RECOVER ... SNAPSHOT TIME. For a storage snapshot of a running database, Oracle recommends placing the database in backup mode immediately before the snapshot and ending backup mode immediately afterward:

ALTER DATABASE BEGIN BACKUP;
-- Create the coordinated storage snapshot.
ALTER DATABASE END BACKUP;

Recovery uses RECOVER ... UNTIL TIME or an SCN after the completion of END BACKUP, not the desupported snapshot-time syntax. The required archived redo must be backed up and restored separately. This short sequence is only the database portion of a snapshot procedure. Storage ordering, cluster behavior, control-file handling, archived-redo protection, and vendor support must be tested for the specific platform. RMAN remains Oracle's recommended database-aware backup and recovery method.

Consistent Offline RMAN Backups

A consistent whole-database backup begins with a clean shutdown. Oracle completes the required checkpoint work so all data files are synchronized to a common SCN. The instance can then be started and the control file mounted without opening the CDB for application access. RMAN creates the backup while the database remains mounted.

The following example creates consistent image copies through configured DISK channels:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP AS COPY
  DATABASE
  TAG 'CONSISTENT_IMAGE_COPY';
ALTER DATABASE OPEN;

1. SHUTDOWN IMMEDIATE performs a consistent shutdown.
2. STARTUP MOUNT starts the instance and mounts the control file without opening the target CDB.
3. BACKUP AS COPY DATABASE creates one disk image copy for each eligible database file.
4. The tag provides a recognizable repository label for the related copies.
5. ALTER DATABASE OPEN restores normal application availability after the backup completes.

After this backup is restored to its backup SCN, media recovery is not required merely to open the database at that point. However, transactions committed after the backup are not present unless later archived redo is available and deliberately applied. The database also continues to have online redo log files while it is closed. The recovery advantage comes from the synchronized checkpoint, not from the absence of redo logs.

An offline backup is not automatically consistent. A backup made after an instance failure or SHUTDOWN ABORT remains inconsistent because Oracle did not complete a clean shutdown. Oracle must first perform instance recovery. The database must then be shut down with NORMAL, IMMEDIATE, or TRANSACTIONAL before it is mounted for a consistent backup.

RMAN does not automatically perform this entire sequence whenever an administrator requests an "offline backup." The administrator, scheduler, Enterprise Manager Cloud Control job, or other orchestration system must explicitly define the shutdown, mount, backup, and reopen steps. RMAN channels perform the database-aware backup work regardless of which supported interface schedules the job.

NOARCHIVELOG Restrictions

When a database runs in NOARCHIVELOG mode, RMAN cannot create an open whole-database backup. The database must be closed consistently and mounted. Without archived redo, recovery normally returns the database to the consistent backup point. Transactions committed after that backup cannot be reconstructed from archived logs that were never created.

NOARCHIVELOG mode is not categorically invalid. It can be appropriate when planned downtime and possible data loss satisfy the organization's recovery point objective, recovery time objective, and availability requirements. Production databases that require online backup and point-in-time recovery normally operate in ARCHIVELOG mode.

If the most recent termination was an abort or instance failure, mounting the database does not transform its files into a consistent backup. Allow instance recovery to complete, perform a clean shutdown, and then mount the database for backup. This distinction prevents a physically closed database from being mislabeled as a consistent recovery point.

CDB and PDB Backup Scope

Oracle 26ai uses the multitenant architecture, so every backup example must have a clear container scope. When RMAN is connected to the CDB root, BACKUP DATABASE protects the complete target CDB according to the documented eligibility rules. A root-connected session can use BACKUP PLUGGABLE DATABASE to protect one or more named PDBs. When RMAN is connected directly to a PDB, BACKUP DATABASE applies to that PDB, subject to the documented privilege and connection requirements.

Tablespace names can be repeated in different PDBs, so connection context matters. Backing up one PDB also does not automatically produce a complete CDB protection plan. Recovery can depend on CDB root metadata, the target control file or recovery catalog, required archived redo, and other container-specific assets. A dedicated administrative identity granted SYSBACKUP should be used for RMAN target authentication where administrative access is required.

Taking one tablespace or data file offline does not make a whole-database backup consistent. Consistency must be evaluated across the complete set of files required by the intended restore and recovery operation.

Validate the Recovery Path

Choose the backup condition from the recovery requirement, not simply from convenience. Online RMAN backups preserve application availability but depend on archived redo and media recovery. Consistent mounted backups provide a straightforward recovery point but require database downtime. User-managed copies can integrate with specific storage technologies, but they require exact coordination of backup mode, file copying, control-file information, archived redo, and RMAN repository metadata.

A production procedure should document the target CDB or PDB scope, log mode, database state, RMAN channel and destination configuration, retention rules, archived-log deletion policy, monitoring, and recovery objectives. LIST reports repository records, CROSSCHECK reconciles recorded status with accessible storage, and validation checks readability. None of those operations replaces a controlled restore and recovery test that demonstrates the required recovery outcome.

In the next lesson, you will compare RMAN backup sets with image copies and select the physical backup format that fits the destination, storage, and recovery requirements.