Preparing for a Closed Database Backup

A consistent closed database backup, traditionally called a cold backup, is a physical backup created after Oracle AI Database has been shut down cleanly. A clean shutdown checkpoints the data files so that they agree at a consistent system change number (SCN). If the complete backup is restored, the database can be opened at that backup point without first applying redo.

The word closed describes the state of the database, not the backup tool. You can create a consistent closed backup with Recovery Manager (RMAN) while the database is mounted but not open, or with approved operating-system or storage-copy tools while the instance remains shut down. RMAN is the preferred method because it understands Oracle file structures, records backup metadata, supports validation, and reduces the chance that an administrator will omit a required database file.

Closed backups require downtime, so they are not the normal choice for systems that must remain continuously available. They remain important, however, for databases operating in NOARCHIVELOG mode, planned maintenance, migrations, laboratory systems, and recovery strategies that require a known consistent copy. In NOARCHIVELOG mode, a consistent closed backup is the only valid whole-database backup. In ARCHIVELOG mode, it is an optional alternative to an online backup.

A closed backup is consistent only when Oracle completes a controlled shutdown. The following commands produce a consistent shutdown:

• SHUTDOWN NORMAL
• SHUTDOWN IMMEDIATE
• SHUTDOWN TRANSACTIONAL

SHUTDOWN IMMEDIATE is the usual administrative choice. It prevents new connections, disconnects current sessions, rolls back uncommitted transactions, and closes the database consistently without waiting for every user to disconnect voluntarily.

SHUTDOWN ABORT, an instance crash, or a power failure does not create a consistent state. Files copied after one of those events may require recovery before they can be opened. If the previous termination was not clean, start the database so Oracle can perform instance recovery, then issue a clean shutdown before creating the backup.

Consistency applies to the complete file set. Copying some data files before shutdown and the rest afterward does not produce a consistent whole-database backup. The administrator must establish the required database state first and preserve that state until the selected backup method has finished.

Most preparation should occur while the database is still open. The goal is to make the downtime predictable and prevent file-discovery work from beginning after users have already lost access. The backup plan should identify:

1. The complete container database (CDB) being protected, including its database name, DBID, root, seed, and pluggable databases.
2. Whether RMAN or a user-managed copy will create the backup.
3. The database logging mode and the recovery point the backup is expected to provide.
4. Every permanent data file and the current control-file configuration.
5. The SPFILE or PFILE and the security assets required to start and access the restored database.
6. A backup destination with sufficient capacity, appropriate permissions, and separation from the primary storage failure domain.
7. The validation, retention, and restore-test procedures that will demonstrate recoverability.

Do not consider a second directory on the same vulnerable storage system to be independent protection. A useful recovery copy should not share every failure mode, credential, administrative boundary, or deletion path with the primary database files. ASM redundancy, RAID, snapshots, replication, and multiplexing can improve availability, but they do not replace a separately retained and tested backup.

Oracle AI Database 26ai uses the multitenant architecture. A whole-database backup in this lesson means a backup of the complete CDB. Before the shutdown, connect to the CDB root with the appropriate SYSBACKUP or SYSDBA administrative privilege and collect an up-to-date inventory. File locations may be conventional file-system paths, Oracle Managed Files, ASM aliases, clustered storage, or another supported storage representation. Never assume that all database files reside in one directory.

Asset	Copy?	Preparation guidance
Permanent data files	Yes	Protect every permanent data file belonging to the CDB. Missing one file makes the whole-database copy incomplete.
Control files	Yes	Protect the current control file according to the selected RMAN or user-managed procedure. Record every configured member.
SPFILE or PFILE	Yes	Retain the startup parameters needed to mount the restored database. Verify which parameter file the instance actually uses.
Password file	Separately	Protect the password file when remote administrative authentication or the recovery design depends on it.
TDE keystore or wallet	Separately	Encrypted data is unusable without its keys. Protect the keystore, passwords, credentials, and opening procedure independently.
Archived redo logs	As required	In ARCHIVELOG mode, retain the archived redo required to recover beyond the consistent backup point.
Online redo logs	No	Inventory their members when useful for recovery documentation, but never copy active online redo logs as backup files.
Temporary files	No	Temporary tablespace tempfiles are not normal backup targets and can be recreated.

Use SQL*Plus and current dynamic-performance or data dictionary views instead of relying on remembered paths. Start by recording the database identity, logging mode, and open state:

SELECT name, dbid, log_mode, open_mode, cdb
FROM   v$database;

List permanent data files and retain the container identifier:

SELECT file#, name, status, con_id
FROM   v$datafile
ORDER  BY con_id, file#;

To relate data files to tablespaces across the CDB, query CDB_DATA_FILES from the root. When connected inside one container, DBA_DATA_FILES provides the current-container view.

SELECT con_id, tablespace_name, file_name
FROM   cdb_data_files
ORDER  BY con_id, tablespace_name, file_name;

List the current control-file members:

SELECT name
FROM   v$controlfile;

You can also document the online redo members, but the result is an inventory only. The listed files are not input to the closed backup:

SELECT group#, member
FROM   v$logfile
ORDER  BY group#, member;

Finally, confirm the startup and control-file parameters used by this instance:

SHOW PARAMETER spfile
SHOW PARAMETER control_files

View or command	Purpose during preparation
V$DATABASE	Records the database identity, DBID, logging mode, open mode, and CDB status.
V$DATAFILE	Lists the permanent data files known to the control file, including file and container identifiers.
CDB_DATA_FILES	Maps accessible CDB data files to their containers and tablespaces.
V$CONTROLFILE	Lists the current control-file members.
V$LOGFILE	Documents online redo members for configuration records. These active files must not be copied as backups.
REPORT SCHEMA	Provides an RMAN view of the target database's tablespaces, permanent data files, and temporary files.

The following diagram combines the file-inventory checks, clean shutdown, and two supported backup paths. Notice that RMAN works with a mounted database, while the user-managed path copies files with the instance down.

Both methods can create a consistent physical backup, but they do not provide the same operational safeguards. RMAN is normally the better choice for production because it discovers database files through Oracle metadata, reads Oracle blocks, records each backup in the RMAN repository, and supports backup sets, image copies, incremental backups, compression, encryption, and validation.

Preparation decision	RMAN closed backup	User-managed closed backup
Database state	Mounted, but not open	Instance shut down
File discovery	Uses Oracle metadata	DBA must identify and copy every required file
Backup representation	Backup sets or image copies	Operating-system or storage-level copies
Block-aware validation	Available through RMAN	Not supplied by a basic file-copy utility
Repository metadata	Recorded automatically	Must be documented and maintained by the DBA
Typical use	Preferred for routine production protection	Specialized procedures and carefully managed environments

Before the maintenance window, review the RMAN configuration with SHOW ALL, confirm the destination and retention policy, and verify that the control file and SPFILE will be protected. Enabling control-file autobackup is a common safeguard:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

The following abbreviated RMAN sequence performs a clean shutdown, mounts the database, creates the backup, and reopens the database:

SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
BACKUP DATABASE TAG 'CONSISTENT_CLOSED_BACKUP';
ALTER DATABASE OPEN;

If the instance previously failed or was terminated with SHUTDOWN ABORT, do not assume that its files are consistent merely because the instance is now down. Start the database and shut it down consistently before mounting it for the backup. Oracle's RMAN documentation shows an additional startup and shutdown cycle when the administrator must guarantee consistency after an uncertain prior state.

The example uses the configured default backup destination. A production command may allocate channels, specify a device type or format, encrypt the backup, create image copies instead of backup sets, or apply a retention policy. Those choices do not change the central requirement: a consistent shutdown must occur before the mounted backup begins.

A user-managed backup relies on operating-system or storage tools rather than RMAN to create the physical copies. The DBA is responsible for completeness, naming, destinations, permissions, metadata, and verification. The safe sequence is:

1. Capture the current file inventory and retain it with the backup documentation.
2. Confirm that the destination has enough capacity and does not share the primary storage failure domain.
3. Shut down the CDB with SHUTDOWN NORMAL, IMMEDIATE, or TRANSACTIONAL.
4. Leave the instance down while the approved copy or snapshot operation runs.
5. Copy every permanent data file and the required control-file and startup assets.
6. Verify copy completion before starting the instance.
7. Start the database and review the alert log for unexpected messages.
8. Record the backup time, database identity, file list, destination, checksums, and recovery dependencies.

Do not use an unreviewed wildcard as a substitute for the inventory. A wildcard can omit files stored in another directory or include active files that do not belong in the backup. In an ASM environment, use tools and procedures that understand ASM storage rather than assuming that a normal file-system copy command can read the files.

Supporting assets deserve deliberate treatment. The password file, TDE keystore, wallets, media-management configuration, and Oracle Net configuration are not all data files, but they may be essential to starting the restored instance, opening encrypted data, or making services available. Protect them through the disaster-recovery process and test access to them. Do not store every dependency under the same credentials and deletion controls as the primary database.

A complete consistent backup represents the database at the checkpoint established by the clean shutdown. Restoring every required file permits the database to open at that backup SCN without media recovery. This does not mean that transactions committed after the backup are protected.

For a database in NOARCHIVELOG mode, restoring the most recent consistent backup normally returns the database to that backup point. Changes made after it are lost because the overwritten redo was not archived. This recovery limitation is one reason that production databases with strict recovery-point requirements normally operate in ARCHIVELOG mode.

For a database in ARCHIVELOG mode, a consistent backup can be the starting point for later recovery. Recovery beyond the backup SCN is possible only when all required archived redo, other usable redo, backup metadata, and security dependencies are available. Merely enabling ARCHIVELOG mode does not guarantee recovery to the instant of failure or guarantee zero data loss.

A successful command is evidence that a backup operation ran, not proof that the database can be recovered within its recovery-time objective. For an RMAN backup, review errors and job output, list the resulting backup records, and use the appropriate RMAN validation operations. Useful follow-up commands include:

LIST BACKUP SUMMARY;
RESTORE DATABASE VALIDATE;
RESTORE DATABASE PREVIEW SUMMARY;

RESTORE DATABASE VALIDATE reads the backup needed for a restore without writing restored data files. A preview reports which backups and redo RMAN expects to use, but a preview alone does not read every backup piece. Select validation commands that match the assurance you need.

For a user-managed copy, verify the file list, sizes, checksums, access permissions, storage location, and required encryption material. The most valuable test for either method is a periodic restore in an isolated environment. Mount and open or recover the restored database as appropriate, document the result, and measure the elapsed time. A tested recovery procedure is far more useful than a collection of files that has never been restored.

1. Confirm that the intended scope is the complete CDB.
2. Record the database name, DBID, logging mode, and current container configuration.
3. Choose RMAN or a user-managed copy, with RMAN preferred for routine production use.
4. Inventory all permanent data files, control-file members, and required startup and security assets.
5. Document online redo members, but exclude active online redo logs from the backup.
6. Verify the backup destination, capacity, permissions, encryption, and failure-domain separation.
7. Perform a clean shutdown. If the prior state is uncertain, restart and shut down cleanly.
8. Mount the database for RMAN, or leave the instance down for a user-managed copy.
9. Create the backup and review every reported warning or error.
10. Reopen the database only after successful completion.
11. Record the backup metadata, retention requirements, and recovery dependencies.
12. Validate the backup and periodically test a complete restore and recovery.

The next lesson shows how to perform a closed database backup. The preparation completed here provides the file inventory, consistent database state, destination, and verification plan required for that procedure.