| Lesson 8 | Performing an open database backup in Oracle |
| Objective | List the steps to perform an open database backup. |
Performing an Open Database Backup with RMAN
An open, or online, database backup protects database files while Oracle AI Database 26ai remains available to applications. Users can continue reading and modifying data while Recovery Manager, or RMAN, reads the data files. This approach avoids the planned outage required for a consistent closed backup and is the normal choice for self-managed production databases that must remain available.
An online backup has an important recovery consequence. Because database writes and checkpoints continue during the operation, the backed-up data files do not represent one common instant. The backup is therefore inconsistent, which is an expected condition rather than an error. After a restore, Oracle must apply the required redo to make the files consistent at the selected recovery point.
For an open backup of active data files, the database must operate in ARCHIVELOG mode. Filled online redo logs are archived before they
can be reused, preserving the history required for media recovery. RMAN is the recommended method because it discovers database files, understands
Oracle block structure, records backup metadata, and integrates backup creation with restore, recovery, and validation.
Recommended Oracle 26ai Workflow
The following procedure illustrates a whole-container-database backup. Connect to the CDB root as a common user with the SYSBACKUP or
SYSDBA administrative privilege. SYSBACKUP is often preferred when duties are separated because it grants authority for
backup and recovery without granting every capability associated with SYSDBA.
The commands are an instructional starting point. A production runbook must also define backup destinations, retention, encryption, compression, channels, archived-log deletion policy, monitoring, and restore-test frequency.
Step 1: Confirm the Database State
Before starting RMAN, connect to the CDB root with SQL*Plus or another authorized SQL interface and verify the database name, open mode, and logging mode:
SELECT name, open_mode, log_mode
FROM v$database;For the workflow in this lesson, expect READ WRITE and ARCHIVELOG. Also verify that archive destinations are available and
that the backup destination has enough capacity. An open backup cannot provide the intended recovery capability if required archived redo is missing,
corrupt, or deleted too early.
This open-state requirement applies to the procedure being demonstrated. RMAN can also back up a mounted database. A database in
NOARCHIVELOG mode requires a consistent shutdown and mounted whole-database backup rather than an open backup of active files.
Step 2: Connect RMAN and Review the Configuration
Connect RMAN to the CDB root through an approved local or Oracle Net authentication method. Do not place credentials in a command file, web page, or shell history. A local operating-system-authenticated connection can look like this when it is permitted by the environment:
rman target /Review the persistent RMAN settings before relying on them:
SHOW ALL;The output can reveal configured device types, channels, retention policy, backup optimization, compression, encryption, and control-file autobackup settings. Confirm these settings against the approved recovery design rather than accepting defaults without review.
If control-file autobackups are not already enabled by policy, enable them:
CONFIGURE CONTROLFILE AUTOBACKUP ON;A control-file autobackup protects the current control file and, when the instance uses one, the server parameter file. This is especially important when the RMAN repository in the control file is needed to locate backups during disaster recovery. Control-file autobackups complement the database backup, but they do not protect password files, wallets, TDE keystores, Oracle Net files, or external application data.
Step 3: Back Up the Open Database and Archived Redo
Run the following RMAN command while the database remains open:
BACKUP DATABASE PLUS ARCHIVELOG;The DATABASE portion backs up the data files in the connected database scope. PLUS ARCHIVELOG performs archived redo log
backup operations and log switches so the operation can include redo through the backup window. RMAN creates separate backup sets for database files
and archived redo; they remain coordinated parts of the same operation.
Applications can remain connected during the backup. RMAN reads Oracle blocks through database server sessions and verifies block structure as it
reads. If RMAN detects a possible fractured block by comparing the block header and footer, it rereads the block. RMAN also captures the checkpoint
information needed for recovery. For these reasons, do not issue ALTER DATABASE BEGIN BACKUP or
ALTER TABLESPACE ... BEGIN BACKUP before an RMAN backup.
RMAN's fractured-block handling does not make an online backup consistent at creation time. If the data files are later restored, RMAN must apply redo to bring them to a consistent SCN. The necessary redo may come from archived redo logs and, when available and applicable, online redo logs. Recovery succeeds only to a point supported by the surviving recovery chain.
Step 4: Review, Validate, and Test
After RMAN reports that the backup completed, review the recorded backup inventory:
LIST BACKUP SUMMARY;Confirm that the expected database, archived redo, control-file, and SPFILE records are present. A listing reports RMAN repository metadata; it does not read every block from every backup piece. Use validation to determine whether the backup files required for a restore are accessible and readable:
RESTORE DATABASE VALIDATE;RMAN also provides VALIDATE and BACKUP ... VALIDATE for other validation objectives. Review every warning and error rather
than relying only on a job-completed message. Crosscheck repository records against their physical media when operational procedures require it.
Validation is necessary, but it is not the final proof of recoverability. Periodically restore and recover the database in an isolated environment. Verify access to backup media, archived redo, credentials, encryption keys, network paths, and sufficient recovery capacity. Measure the actual recovery point and elapsed recovery time so the organization knows whether the procedure satisfies its RPO and RTO.
BEGIN BACKUP; the
user-managed alternative requires coordinated backup mode, file copying, and preservation of the required redo.
What the RMAN Backup Protects
BACKUP DATABASE PLUS ARCHIVELOG is intentionally concise, but its scope should not be misunderstood. RMAN backs up physical database
files and archived redo supported by the command and connection context. A complete disaster-recovery plan must account for additional dependencies.
| Asset | How it is protected | Why it matters |
|---|---|---|
| Data files | Included by BACKUP DATABASE for the connected CDB scope |
Contain permanent database blocks that RMAN restores before applying recovery changes. |
| Archived redo logs | Included by the PLUS ARCHIVELOG portion as separate backup sets |
Supply changes needed to make restored online backups consistent and advance them toward the recovery target. |
| Control file and SPFILE | Protected through documented RMAN inclusion rules and preferably a configured control-file autobackup | Describe database structure, initialization, and RMAN repository information needed during restore. |
| Password files and configuration | Protected by a separate disaster-recovery process | May be required to authenticate, connect, start services, and rebuild the environment. |
| Wallets and TDE keystores | Protected separately with controlled credentials and access procedures | Encrypted backups and data files can be unusable if their keys are lost. |
| External files | Protected by the applicable host, storage, or application procedure | External tables, directories, and application-managed files are not automatically included in a database backup. |
Keep at least one recoverable copy outside the primary database storage failure domain and administrative boundary. A backup stored on another directory of the same vulnerable array may be lost with the database. Consider storage systems, credentials, encryption domains, hosts, availability zones or regions, and protection from accidental or malicious deletion.
User-Managed Online Backup Alternative
User-managed operating-system copies remain supported, but they require the DBA to coordinate Oracle backup mode, file inventory, copying, redo retention, and recovery metadata. Use this method only when an operational requirement or validated storage integration justifies the additional responsibility. Cataloging a user-managed copy in RMAN later does not retroactively provide the safeguards RMAN would have applied while creating it.
Identify the Data Files
Before copying a permanent tablespace, connect to the correct CDB or PDB container and identify every data file belonging to the intended scope:
SELECT tablespace_name, file_id, file_name
FROM dba_data_files
ORDER BY tablespace_name, file_id;Use the complete inventory. Do not assume that a wildcard such as *.dbf identifies every required file or only files belonging to the
target database. Such assumptions are especially unsafe with ASM, Oracle Managed Files, multiple database homes, and storage layouts that span
several locations.
Do not copy online redo log members as normal backup files. They are active fault-tolerance files maintained by Oracle. Multiplexing online redo members can improve availability, but the recovery plan protects redo history by backing up archived redo logs and preserving any surviving online redo needed for the failure scenario.
Understand the Data File Header
A data file header contains identity and checkpoint information that Oracle uses during recovery. The checkpoint is represented by a system change number, or SCN, rather than a simple wall-clock timestamp. During a user-managed online backup, backup mode controls relevant checkpoint advancement in the header and ensures that redo contains the information needed to recover copied blocks.
A copy utility does not understand Oracle block boundaries. It can read a block while database writer is modifying that block, producing a fractured copy whose header and footer come from different versions. While the file is in backup mode, Oracle records the whole changed block information needed to reconstruct it during media recovery. This protection generates more redo than normal change-vector logging.
Begin Backup Mode and Copy the Files
For a coordinated copy of all eligible online read/write data files, begin database backup mode:
ALTER DATABASE BEGIN BACKUP;This statement does not copy any file. After it succeeds, use the approved operating-system or storage procedure to copy every inventoried data file
to protected storage. The exact copy command depends on the platform, storage technology, permissions, and consistency guarantees, so a generic
Windows COPY command is not an appropriate universal example.
For a smaller scope, the DBA can place one read/write tablespace in backup mode with ALTER TABLESPACE ... BEGIN BACKUP, copy its data
files, and end backup mode before proceeding to another tablespace. Serial processing can limit the number of busy files in backup mode and reduce
excess redo generation.
Tempfiles are not normal physical backup targets because temporary contents can be recreated. Current Oracle databases use undo tablespaces and automatic undo management, not legacy rollback-segment tablespaces. A user-managed copy of an online read-only tablespace does not require backup mode while the tablespace remains read-only, although its valid backup and control-file metadata still must be preserved.
End Backup Mode and Preserve Redo
End backup mode as soon as copying finishes, then force a log switch:
ALTER DATABASE END BACKUP;
ALTER SYSTEM ARCHIVE LOG CURRENT;The log switch helps ensure that redo required through the end of the copy becomes archived. Preserve those archived logs together with the copied data files and a suitable control-file backup. The resulting file copies are inconsistent and require media recovery after restoration.
If an instance fails while files are in backup mode, inspect V$BACKUP as part of the recovery assessment:
SELECT file#, status, change#, time, con_id
FROM v$backup
WHERE status = 'ACTIVE';Do not issue END BACKUP blindly if files may have been restored. First determine whether they are current data files or restored copies,
then follow the appropriate media-recovery procedure. Leaving current files in backup mode generates unnecessary redo and can interfere with normal
operations.
A storage snapshot of an open database needs equivalent coordination. Use technology validated for Oracle online backups, take the relevant files
offline, or surround the snapshot with the supported backup-mode procedure. Oracle AI Database 26ai desupports
RECOVER ... SNAPSHOT TIME; use currently supported recovery to a specified time or SCN and retain the necessary archived redo.
RMAN and User-Managed Methods Compared
| Characteristic | RMAN online backup | User-managed online copy |
|---|---|---|
| Recommended role | Normal production method | Specialized alternative |
| Database availability | Database remains open | Database remains open |
ARCHIVELOG requirement | Required for an open backup of active files | Required for an open backup of active files |
| File discovery | RMAN discovers files in the requested scope | DBA must inventory every file |
| Backup mode | No BEGIN BACKUP or END BACKUP | Required for online read/write data files unless validated technology supplies equivalent protection |
| Fractured-block handling | RMAN detects and rereads fractured blocks | Relies on backup mode or an Oracle-compatible snapshot procedure |
| Formats and incrementals | Backup sets, image copies, and incremental strategies | Raw image copies or snapshots without native RMAN incremental metadata |
| Repository metadata | Recorded automatically | Managed by the DBA; valid copies can later be cataloged |
| Redo after restore | Required to make an online backup consistent | Required to make an online copy consistent |
Redo and Recovery Implications
LGWR writes redo records from the redo log buffer to members of the current online redo log group. When a log switch occurs, writing advances to
another group. In ARCHIVELOG mode, a filled group must be archived before Oracle can reuse it. This archived history allows media recovery
to reproduce logged changes after a restored backup's checkpoint.
The backup procedure must retain every archived redo log required from the selected backup checkpoint to the intended recovery point. If part of
that sequence is unavailable, recovery may stop earlier than the business requires. ARCHIVELOG mode alone does not guarantee zero data
loss. The actual result depends on the backups, archived redo, surviving online redo, standby protection when present, and the failure scenario.
Some NOLOGGING operations can create data changes that redo cannot fully reconstruct. After significant NOLOGGING work,
back up the affected data files according to the recovery policy. A large collection of archived logs cannot reconstruct information that was never
fully logged.
Storage redundancy and replication also do not replace backup. ASM redundancy, RAID, snapshots, Data Guard, and multiplexed control files or redo members can improve availability, but they can reproduce logical corruption, an unwanted database change, or malicious deletion. Maintain multiple recovery points and independently protected copies.
Accept the Backup Only After Testing
A robust open-backup process has two outcomes: verified backup media and evidence that the organization can recover from it. Monitor RMAN job completion, investigate warnings, crosscheck repository records when appropriate, and validate the files. Keep records of backup duration, throughput, archived-redo volume, and destination capacity so operational trends are visible before they become failures.
Restore tests should exercise the same dependencies required during an emergency. Confirm that recovery personnel can obtain credentials and TDE keys, reach protected storage, restore the control file and SPFILE when necessary, restore database files, apply redo, and open the recovered database according to the runbook. Record the achieved recovery point and total recovery time.
An RMAN online backup is therefore more than a command executed while users remain connected. It is one step in a tested recovery chain. The next lesson explains the methods and commands used to back up a control file.
Performing Backup - Quiz
Use the following quiz to review your understanding of open database backups and their recovery requirements.
Performing Backup - Quiz