Creating User-Managed Image Copies in Oracle 26ai

Yes. Oracle AI Database 26ai can use operating-system or storage-created files as user-managed image copies. The copy must be a complete disk image of one supported database file, it must be created with the consistency safeguards required for that file's state, and it must be cataloged before RMAN can select it automatically.

An image copy can represent one data file, control file, or archived redo log. An externally created copy is called a user-managed backup or operating-system backup. Its physical form can resemble an image copy created by BACKUP AS COPY, but its creation and repository workflow are different.

A file utility understands bytes and paths, not Oracle block consistency or recovery requirements. The DBA is responsible for selecting a recoverable point, copying every required file, preserving the necessary redo, protecting the destination, and registering the result. For most routine backup policies, RMAN-created copies remain preferable because RMAN checks database blocks while copying and records the completed copy automatically.

Both methods can produce one disk file for each source database file. The important differences involve who understands the Oracle data and who records the backup metadata.

RMAN-created and user-managed image copies

Characteristic	RMAN-created image copy	User-managed image copy
Creation	BACKUP AS COPY	Operating-system, snapshot, split-mirror, or storage tool
Repository record	Recorded automatically when RMAN completes the copy	Added later with CATALOG
Block handling	RMAN reads and checks Oracle blocks while copying	Depends on the external tool and consistency procedure
Backup mode	Not required for an RMAN backup	Required when an OS tool copies an online read/write tablespace
Tags and parallelism	Controlled through RMAN syntax and configuration	Not supplied by the OS copy command
Output	One disk file for each copied source file	One disk file for each copied source file

RMAN understands Oracle block structure and protects against fractured blocks while it reads. A generic utility can copy a block while the database writer is changing it. The destination could contain the beginning of the block from one point in time and the end from another. Such a block is not consistent with one system change number and may make recovery fail.

For that reason, the physical similarity between the two types of copy does not imply identical reliability. User-managed copies are useful for documented storage-snapshot workflows, split mirrors, existing operational procedures, and special integration requirements. They are not a shortcut around Oracle's consistency and recovery rules.

The correct procedure depends on whether the database file is online, offline, read/write, read-only, or changing under a storage snapshot. The principal consistency choices are:

1. Create a closed backup after a clean database shutdown.
2. Take an eligible tablespace offline normally before copying its data files.
3. Place an online read/write tablespace in backup mode, copy all its data files, end backup mode, and archive the current redo.
4. Use an Oracle-supported and vendor-documented snapshot or split-mirror procedure with its required backup-mode or I/O controls.

An ordinary storage snapshot is not automatically application-consistent. A crash-consistent storage image and an Oracle-recoverable backup are not necessarily the same. The procedure must preserve the database files and redo state needed to recover from the snapshot checkpoint.

Before an online user-managed data-file backup, confirm that the database is in ARCHIVELOG mode. Identify every data file in the selected scope, exclude temporary tablespaces, verify destination capacity and permissions, and make sure all required archived redo will be retained. The administrative connection must also have the appropriate privileges, commonly SYSBACKUP or SYSDBA.

Do not rely on an old hard-coded data-file name. Query the current container's data dictionary to identify every data file in the tablespace:

SELECT tablespace_name, file_name
FROM sys.dba_data_files
WHERE tablespace_name = 'USERS';

The query can return several rows. Every listed data file belongs to the planned tablespace copy. The destination must provide sufficient space for their complete sizes, because image copies retain the source files' physical layouts.

For an online read/write tablespace, place the tablespace in backup mode and wait for the statement to complete before starting the external copy:

ALTER TABLESPACE users BEGIN BACKUP;

Copy each identified data file with the appropriate host or storage utility. This Linux example uses illustrative paths:

cp /u01/oradata/CDB1/users01.dbf /backup/imgcopies/users01.dbf

The source and destination paths must match the actual environment. A database may use several mount points, Oracle Managed Files, ASM, or PDB-specific storage. One successful copy command does not prove that every file in the tablespace was included.

As soon as all files in the tablespace have been copied, end backup mode and archive the current redo:

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

BEGIN BACKUP changes how Oracle generates redo for the affected files so recovery can address blocks copied while they were being modified. The file copy must not begin before that statement completes, and END BACKUP must not run until the external copy finishes. Archiving the current redo helps ensure that changes required to recover the copied checkpoint are available in archived form.

Backup mode increases redo generation because Oracle may write full images of changed blocks to redo. Leaving a tablespace in backup mode can create performance problems and interfere with database shutdown. Keep the interval short. When several tablespaces must be copied, serial processing is often preferable because it minimizes the time and additional redo associated with each backup-mode window.

An eligible tablespace can be taken offline normally before its data files are copied. This method avoids copying files while database writer processes are modifying them:

ALTER TABLESPACE users OFFLINE NORMAL;

After the statement succeeds, copy every data file belonging to the tablespace:

cp /u01/oradata/CDB1/users01.dbf /backup/imgcopies/users01_offline.dbf

Bring the tablespace online and archive the current redo:

ALTER TABLESPACE users ONLINE;
ALTER SYSTEM ARCHIVE LOG CURRENT;

OFFLINE NORMAL checkpoints the files and is preferred when application availability permits the tablespace to be taken offline. The SYSTEM tablespace and a tablespace containing active undo segments cannot use this tablespace-offline procedure. Application dependencies can also make an otherwise eligible tablespace impractical to take offline.

Do not substitute OFFLINE IMMEDIATE or OFFLINE TEMPORARY without understanding the recovery consequence. Those modes can require tablespace recovery before the files return online.

A cleanly shut down and mounted database can also be copied as a consistent closed backup. That is a separate procedure that must protect all required data files, control files, parameter files, keystores, and environmental dependencies. Copying one file after a clean shutdown is not by itself a complete database backup.

Data files, control files, and redo files do not share one generic copy procedure. A current control file changes as the database operates. Instead of using a raw OS copy of an active control file, use RMAN or Oracle's SQL command for creating a binary control-file backup:

ALTER DATABASE BACKUP CONTROLFILE
  TO '/backup/imgcopies/control01.ctl' REUSE;

The resulting binary file can be entered in the RMAN repository with the control-file-specific catalog command:

CATALOG CONTROLFILECOPY '/backup/imgcopies/control01.ctl';

BACKUP CONTROLFILE TO TRACE has a different purpose. It produces a text script that can help recreate a control file; it is not a binary control-file image copy.

For archived redo, copy only completed archived log files that are no longer being written. Register the new path using the matching object type:

CATALOG ARCHIVELOG '/backup/arch/arch_101_1.arc';

Never copy or restore online redo logs as user-managed backups. Restoring an old online redo log can create conflicting archived logs with the same sequence number but different contents. Protect completed archived logs and use Oracle recovery procedures to manage redo.

After an external data-file copy has been created correctly, connect RMAN to the target database. The target must be mounted or open, and the file being cataloged must be on disk-accessible storage. A separate recovery catalog is optional for this ordinary operation because the target control file is always an RMAN repository.

Catalog the exact path as a data-file copy:

CATALOG DATAFILECOPY '/backup/imgcopies/users01.dbf';

RMAN reads identifying header information and records the copy in the repository. Once the copy is cataloged, accessible, and otherwise eligible, RMAN can consider it for supported RESTORE and SWITCH operations. Cataloging makes RMAN aware of the copy; it does not create another copy.

A correctly created data-file copy can also be recorded as a level 0 incremental base:

CATALOG DATAFILECOPY '/backup/imgcopies/users01.dbf'
  LEVEL 0 TAG 'OS_LEVEL0';

Zero is the only valid LEVEL value for this catalog operation. The command does not transform, update, or recopy the file. It tells RMAN to record the existing data-file copy as a possible level 0 base for a supported incremental strategy. The tag is a reusable repository label and does not prove that the copy is valid.

Do not record every OS copy automatically as level 0. The incremental design must account for the copy's checkpoint, later incremental backup sets, redo, update schedule, retention, and recovery tests.

When a reviewed backup location contains several eligible files, CATALOG START WITH can search by file-name prefix:

CATALOG START WITH '/backup/imgcopies/' NOPROMPT;

The string is a strict prefix rather than a wildcard expression. RMAN can discover valid backup pieces, data-file copies, control-file copies, and archived redo logs whose names begin with the prefix. Files that do not represent catalogable objects are reported rather than silently converted into backups.

NOPROMPT suppresses confirmation for each match. Use it only after verifying the location and its contents. An overly broad prefix can discover files that were not intended for this database or operation. Review the RMAN output to see which files were cataloged, skipped, or rejected.

CATALOG checks identifying header information. It does not read every block for corruption, guarantee that the file was copied completely, or prove that an online data file was placed in backup mode at the required time.

The responsibilities remain divided as follows:

• The external utility or storage system must produce a complete byte copy.
• The database and storage procedure must establish a recoverable consistency point.
• The administrator must include the required files, redo, keystores, metadata, and configuration.
• RMAN checks the supplied object's header and records eligible metadata.
• The backup policy must include validation and restore-and-recovery testing.

After cataloging, inspect the repository and confirm that the files remain accessible:

LIST COPY;
CROSSCHECK COPY;

LIST COPY displays repository records. CROSSCHECK COPY compares those records with files that RMAN can access and updates status where appropriate. Neither command performs a complete block scan or proves that a recovery will succeed.

Storage snapshots and split mirrors can create user-managed image copies efficiently, but the storage operation must follow Oracle's requirements and the vendor's database-consistency procedure. Depending on the technology, the workflow may require tablespace backup mode, ALTER DATABASE BEGIN BACKUP, or database I/O suspension before the snapshot or mirror is separated.

Keep the consistency window short, end backup mode or resume I/O promptly, and preserve the redo needed to recover the snapshot. Do not include online redo logs in a split-mirror backup. Prefer an Oracle-created binary control-file backup rather than depending on a split copy of an active control file.

After the stable mirror or snapshot files become accessible as complete disk files, catalog them with the correct RMAN object types. If a temporary mirror is later rejoined, deleted, or made inaccessible, remove its stale repository record:

CHANGE DATAFILECOPY '/backup/mirror/users01.dbf' UNCATALOG;

UNCATALOG removes the RMAN repository record; it does not delete the operating-system file. Verify the intended path and storage lifecycle before issuing the command.

A normal host cp command cannot treat an ASM disk-group file as an ordinary mounted file-system path. For ASM-managed files, prefer BACKUP AS COPY, an Oracle-supported ASM-aware utility, or a documented storage integration. An ASM-aware copying mechanism still does not eliminate database-consistency, redo, repository, capacity, and recovery-testing requirements.

A user-managed file copy does not acquire RMAN backup-set compression or password-based backup encryption. A data file protected by Transparent Data Encryption retains the encryption stored in its data blocks, but successful recovery also depends on preserving and protecting the required Oracle keystore.

The backup location needs appropriate ownership, permissions, access control, monitoring, replication, retention, and secure disposal. Avoid placing sensitive database copies in broadly accessible directories. File-system security is part of the backup design, not an optional task after the copy finishes.

An exact image copy is also not automatically portable across hardware or operating-system platforms. Oracle cross-platform transport and conversion rules still apply. A file that is usable for same-platform recovery may require conversion or a different transport workflow before another platform can use it.

1. Select the CDB, PDB, tablespace, or file scope and identify every required data file.
2. Choose a documented consistency method appropriate to the current file state.
3. Confirm ARCHIVELOG mode and redo retention for an online user-managed backup.
4. Verify destination permissions, capacity, file naming, security, and lifecycle.
5. Enter backup mode or take files offline when the chosen procedure requires it.
6. Copy every required file and end the consistency window immediately afterward.
7. Archive the current redo and preserve all logs needed to recover the copy.
8. Catalog each file with the correct RMAN object type.
9. List, crosscheck, validate as appropriate, and test restore and recovery.
10. Uncatalog temporary copies when they are no longer accessible.

An operating-system command can duplicate bytes, but only a complete consistency, redo, catalog, and recovery process makes the copy useful as a database backup. Use RMAN-created image copies for routine protection when possible, and use external methods only through a documented, tested procedure.

In the next lesson, you will review how RMAN channels, backup sets, image copies, and repository metadata work together in an Oracle backup and recovery strategy.