Online Backup Options and Fuzzy Datafile Copies

Choose the Appropriate Backup Scope

Oracle AI Database 26ai uses the multitenant architecture. A backup plan can protect the complete container database, the CDB root, one or more pluggable databases, selected tablespaces, or individual data files. The right scope depends on the recovery objective. A narrow backup can protect a frequently changing or operationally important area, but it does not replace periodic protection of the complete CDB and its recovery metadata.

A typical online whole-CDB operation also protects the archived redo needed through the end of the backup:

BACKUP DATABASE PLUS ARCHIVELOG;

RMAN switches and archives redo as part of the operation and creates database and archived redo log backup sets. The command is a useful starting pattern, not a complete production policy. The DBA must still configure destinations, retention, encryption, channels, monitoring, and restore testing. When an individual PDB is backed up, the necessary archived redo also must be protected at the CDB level. A PDB backup without its required redo might not support the intended media recovery.

Choose the Backup Format and Frequency

RMAN can create backup sets or image copies. A backup set is an RMAN-specific structure containing one or more backup pieces. It can omit blocks that do not need to be backed up and can use RMAN compression and encryption. An image copy is a block-for-block representation of one data file, control file, or archived redo log. An image copy can be switched into service during some recovery procedures, while a backup set must be restored by RMAN.

The word full means that a backup is not incremental. It does not necessarily mean that the complete database is included. A full backup can target one data file or one tablespace. Incremental level 0 and level 1 backups provide another way to control backup volume and recovery work. A level 0 establishes an incremental baseline. A level 1 captures blocks changed after an applicable earlier backup. Incrementally updated image-copy strategies can roll level 1 changes into an older image copy to maintain a more current recovery copy.

A more recent usable backup can reduce the redo that must be applied after a restore and may improve the recovery-time objective. It does not guarantee a particular recovery duration. Recovery time also depends on the target SCN or time, the database change rate, incremental strategy, storage throughput, channel configuration, and whether all required media can be accessed promptly.

Do not use arbitrary weekly or monthly schedules simply because a tablespace has a particular name. Set frequency according to the organization's recovery-point objective, recovery-time objective, data-change rate, storage capacity, and measured restore performance. Current databases use undo tablespaces and automatic undo management, not legacy rollback-segment tablespaces. Tempfiles are not backed up as ordinary RMAN data files because temporary contents can be recreated. Read-only tablespaces may need less frequent backup, but their valid backups and the control-file metadata that describes their state still must be preserved.

Why an Online Datafile Copy Becomes Fuzzy

Fuzzy Files and Fractured Blocks Are Different

User-Managed Online Tablespace Copies

A user-managed backup can target every data file in an online tablespace or selected data files, but the DBA must identify the correct files before starting. For example, query DBA_DATA_FILES in the correct container to map a read/write tablespace to its data files. Do not rely on a filename pattern that might omit a file or include a file from another database.

The following sequence illustrates a user-managed copy of the online USERS tablespace. The operating-system copy step is deliberately generic because commands, storage paths, permissions, and snapshot facilities differ among environments.

ALTER TABLESPACE users BEGIN BACKUP;

# Copy every inventoried data file belonging to the USERS tablespace.

ALTER TABLESPACE users END BACKUP;
ALTER SYSTEM ARCHIVE LOG CURRENT;

The final log switch archives redo needed through the end of the copy. The DBA must protect that redo together with a suitable control-file backup and the copied data files. For a coordinated copy of all eligible data files, Oracle also supports ALTER DATABASE BEGIN BACKUP and ALTER DATABASE END BACKUP. Placing many busy tablespaces in backup mode simultaneously can generate substantial redo, so a serial tablespace procedure may be more appropriate when using this specialized method.

If an instance fails during a user-managed online backup, query V$BACKUP after mounting or opening the database as appropriate. An ACTIVE status identifies files recorded as being in backup mode:

SELECT file#, status, change#, time, con_id
FROM   v$backup
WHERE  status = 'ACTIVE';

Do not issue END BACKUP blindly after files may have been restored. First determine whether the files are current or restored copies and follow the appropriate recovery procedure. Leaving current files in backup mode increases redo generation and can interfere with normal operations.

Storage snapshots of an open database require the same care. Use snapshot 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. Current snapshot planning uses supported backup coordination and recovery to a specified time or SCN while retaining the necessary archived redo.

Protect the Complete Recovery Chain

Selecting a tablespace or data file is only the first backup decision. Recovery depends on every asset required to interpret, decrypt, restore, and roll that backup forward. A practical recovery chain can include:

• valid data file backup sets or image copies;
• the control file and RMAN control-file autobackups;
• the server parameter file and required initialization information;
• all archived redo logs and incremental backups needed to reach the recovery target;
• RMAN repository metadata in the control file and, when used, a protected recovery catalog;
• TDE keystores, wallets, encryption passwords, credentials, and documented access procedures;
• storage, network, media-management, and recovery runbook information needed to rebuild database service.

Keep recoverable backup copies outside the failure domain and administrative boundary of the primary database storage. ASM redundancy, RAID, storage snapshots, replication, Data Guard, and multiplexed files can improve availability, but none replaces an independently protected and tested backup. Corruption, an unwanted database change, credential compromise, or malicious deletion can be reproduced across redundant storage.

Redo-based recovery also has a limit: some NOLOGGING operations can create changes that redo cannot fully reconstruct. After significant NOLOGGING work, back up the affected data files according to the recovery policy. Do not assume that the presence of archived redo repairs data that was never fully logged.

Validate the Selected Backup Strategy

A successful backup command proves that a job completed, not that the organization can restore service within its objectives. Monitor RMAN job results and errors, crosscheck repository records against physical storage, validate database files and backup pieces, and retain more than one recovery point. An older validated backup can be essential if corruption or an unwanted change existed before the newest backup was created.

Periodically perform a complete restore and recovery in an isolated environment. Verify that the team can access encryption keys, credentials, network paths, media libraries, archived redo, and sufficient recovery capacity. Measure the recovery point and elapsed recovery time during the test. Those measurements show whether the chosen whole-CDB, PDB, tablespace, data-file, and incremental schedules actually satisfy the documented RPO and RTO.

Online backup flexibility is therefore a recovery-planning tool, not permission to protect files independently without context. Choose a scope that matches the failure being addressed, retain the redo and metadata that make the backup usable, and prove the procedure through restoration. The next lesson shows how to perform an open database backup.