| Lesson 9 | Backing up the control file |
| Objective | Explain the methods and commands used to back up the control file. |
Backing Up the Oracle 26ai Control File
The control file is a binary database file containing metadata that Oracle AI Database 26ai needs to identify, mount, operate, and recover a multitenant container database. Oracle opens the control file when an instance mounts the CDB, before the database opens its data files for normal application access.
The control file records the database name and database identifier, or DBID, as well as data file and tempfile names, online redo log groups and members, checkpoints, log sequence information, archived redo history, database incarnations, and RESETLOGS history. It also holds RMAN repository records for backup sets, backup pieces, image copies, and archived redo when the target control file is used as the repository.
A PDB does not have its own control file. The control file is a root-level file that tracks the physical components of the entire CDB, including information needed for its PDBs. Operations that protect or restore the CDB control file are therefore performed from the CDB root with an authorized administrative connection.
Losing every current control-file member prevents the database from mounting with its current metadata, but it does not necessarily make recovery impossible. RMAN can restore a control-file autobackup or another binary backup. If no usable binary backup survives, a DBA may be able to re-create the control file from a current trace script and verified database records. This last option usually requires more manual recovery work.
Control-File Protection Methods
Control-file protection combines availability measures with historical recovery copies. These assets have different purposes and should not be treated as interchangeable.
| Protection asset | Created or maintained by | Primary purpose | Historical recovery point? |
|---|---|---|---|
| Multiplexed current member | Oracle Database and storage configuration | Continue operating after one current copy or storage path fails | No |
| RMAN control-file autobackup | RMAN configuration and qualifying backup or structural-change events | Recover the SPFILE, control file, and RMAN repository path after a major loss | Yes |
| Explicit RMAN backup | BACKUP CURRENT CONTROLFILE or inclusion in another RMAN backup |
Create an intentional binary backup recorded in the RMAN repository | Yes |
| SQL binary backup | ALTER DATABASE BACKUP CONTROLFILE TO 'file' |
Create a user-managed binary recovery copy | Yes |
| Control-file trace script | ALTER DATABASE BACKUP CONTROLFILE TO TRACE |
Generate editable CREATE CONTROLFILE text for re-creation |
No, it is not a binary backup |
| RMAN snapshot control file | RMAN internal processing | Provide a read-consistent view of changing control-file metadata | No |
A sound design normally uses multiplexed current members and independently protected control-file backups. Multiplexing improves availability, while autobackups and explicit backups provide earlier copies that can be restored. One cannot replace the other.
Oracle AI Engineering
Configure RMAN Control-File Autobackups
RMAN control-file autobackup is the recommended primary recovery mechanism. Begin by inspecting the actual target database configuration rather than assuming a default:
SHOW CONTROLFILE AUTOBACKUP;If the feature is not enabled according to the approved recovery policy, configure it:
CONFIGURE CONTROLFILE AUTOBACKUP ON;The autobackup occurs independently of an explicit current control-file backup requested in a BACKUP command. RMAN uses a well-known filename format, normally based on the %F substitution variable, so it can search for the autobackup when the current control file and recovery catalog are unavailable. This property is essential during disaster recovery because the control file itself contains the usual RMAN backup
inventory.
If the database instance uses an SPFILE, RMAN writes the SPFILE and control file to the same autobackup backup piece. After the autobackup completes, Oracle records the complete path and device type in the alert log. The recovery runbook should preserve this destination information together with the DBID, any custom autobackup format, media-management configuration, encryption information, and credentials needed to retrieve the piece.
RMAN creates an autobackup after qualifying backup activity. For an ARCHIVELOG database, it can also create one after structural changes
that alter control-file metadata. When several structural changes occur within a short interval, Oracle may create one autobackup covering the group
instead of one file for every SQL statement.
The automatic structural-change backup does not occur for a database operating in NOARCHIVELOG mode. Such an environment needs an
explicit procedure to protect the updated control file after structural changes. In either logging mode, verify the actual backup result rather than
assuming that configuration alone produced a usable file.
Understand Autobackup Limitations
A control-file autobackup is stored in its own backup set. Oracle documents that these autobackups are never duplexed, and one autobackup operation cannot be configured to write the same autobackup to multiple locations. If policy requires another destination, create an explicit backup or use an approved storage, media-management, or replication process to protect another copy.
The autobackup does not include every asset required to rebuild database service. Password files, Oracle wallets, TDE keystores, Oracle Net and listener files, storage configuration, media-management credentials, and recovery runbooks need separate protection. An encrypted database or backup can be unrecoverable if its keys are lost even when the control-file autobackup remains readable.
Create an Explicit RMAN Control-File Backup
RMAN can back up the current control file while the database is mounted or open. The simplest explicit command creates a control-file backup set at the configured destination:
BACKUP CURRENT CONTROLFILE;An explicit backup can also be included with another RMAN operation. The following example backs up a tablespace and includes the current control file:
BACKUP TABLESPACE users
INCLUDE CURRENT CONTROLFILE;To create an image copy at an explicitly selected destination, use an environment-appropriate format:
BACKUP AS COPY CURRENT CONTROLFILE
FORMAT '/protected/path/control01.ctl';The path is illustrative. A production environment may use a fast recovery area, ASM disk group, file system, SBT media-management channel, supported cloud storage integration, or Recovery Appliance. The destination must follow the organization's retention, encryption, access-control, and failure-domain requirements.
When RMAN creates a control-file backup set, it first creates a snapshot control file to obtain a read-consistent view. The snapshot control file is a temporary working copy. It is not a historical disaster-recovery backup. In an Oracle RAC environment, its configured location must be on shared storage accessible from the participating instances.
If control-file autobackup is enabled, an explicit backup command can result in both the requested control-file backup and a separate autobackup. The autobackup occurs after the requested files are backed up, so it contains metadata about the operation that just completed. This timing is one reason an autobackup can be especially useful when reconstructing the RMAN repository during a disaster.
Create a User-Managed Binary Backup
Oracle AI Database 26ai also supports a SQL command that creates a binary copy of the current control file:
ALTER DATABASE BACKUP CONTROLFILE
TO '/protected/path/cf.bak' REUSE;The filename must be fully specified for the target environment. The REUSE clause permits Oracle to overwrite an existing destination
file, so use it only when the runbook intends that replacement. The command requires the ALTER DATABASE privilege.
A binary copy is the preferred user-managed control-file backup because it preserves more recovery information than a text trace script. Depending on the database state and version compatibility, that information can include archived redo history, offline ranges for offline or read-only tablespaces, tempfile entries, and RMAN backup-set and image-copy records stored in the control file.
This SQL command remains a supported supplemental method, but it should not displace RMAN autobackups in a normal production strategy. RMAN records its own backups in the repository, knows the configured devices, and can search for well-known autobackup names during a restore.
Generate a Control-File Trace Script
The trace option creates a text file containing a generated CREATE CONTROLFILE statement:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;The database can be mounted or open when the command runs. Oracle writes the trace into the Automatic Diagnostic Repository under a location governed
by DIAGNOSTIC_DEST. Consult the database alert log to identify the exact trace filename and path.
The trace is not a binary control-file backup. It is editable SQL that can help a DBA re-create a control file if no current member or usable binary backup remains. It describes the database structure known when the trace was generated, including data file and online redo log clauses. If the database structure changes later, an older script can be stale or incomplete.
A generated trace may contain alternatives for RESETLOGS and NORESETLOGS, depending on the command options and database
state. It can also include separate commands for recreating tempfiles. The DBA must review the script against the actual recovery scenario and the
files that survived. Do not copy a generated statement between unrelated databases.
Re-creating a control file can require media recovery, registration of archived redo that is not represented in the new control file, handling of
read-only or offline files, and an OPEN RESETLOGS operation. For this reason, a trace script is supplementary recovery documentation and a
last-resort tool, not the preferred daily backup.
The trace contains SQL text, not copies of data files or redo logs. Its size is not derived from the combined size of database files, and there is no
valid formula that doubles those file sizes. Current trace location guidance uses the ADR and alert log, not the obsolete
USER_DUMP_DEST parameter.
Maintain Multiplexed Current Control Files
Multiplexing maintains two or more identical current control-file members. Oracle writes structural and recovery metadata to every configured member. If one storage path fails and another valid member remains available, the surviving copy can reduce the work needed to return the database to service.
Inspect the currently configured members with this query:
SELECT name, block_size, file_size_blks, status
FROM v$controlfile;A valid control file normally has a null value in the STATUS column. Investigate any status that indicates an inaccessible or invalid
member and review the alert log for related errors.
The CONTROL_FILES initialization parameter identifies user-named control-file members. Most modern databases store persistent
initialization settings in an SPFILE. Oracle Managed Files and ASM configurations can determine names and locations through managed storage settings,
so a literal file-system procedure does not apply to every database.
Adding or relocating a current member requires a controlled, tested procedure. The work can include a consistent shutdown, copying a valid current member to protected storage, changing persistent configuration, restarting, and verifying every member. Do not copy a changing current control file with an operating-system utility while the database is mounted or open.
Oracle recommends at least two multiplexed or mirrored current control files on separate storage. Apply this guidance in terms of independent failure domains rather than merely counting disks. Separate logical volumes can still share the same array, controller, host, power source, administrative account, or region.
Multiplexed members are active files, not backup copies. A mistaken structural change or corruption can affect all active members. Retain RMAN autobackups and explicit recovery copies outside the primary storage and administrative boundary.
Protect the Control File After Structural Changes
The control file changes whenever Oracle updates its record of the database's physical structure or recovery state. Examples include adding, dropping, renaming, taking online, or taking offline a data file or tablespace; changing online redo log groups or members; renaming database files; changing tablespace read/write state; adding a redo thread; or enabling or disabling Flashback Database.
After a structural change, confirm that the current control-file members are healthy and that the updated metadata has been protected. For an
ARCHIVELOG database with autobackup enabled, Oracle can create a control-file autobackup automatically. Review the alert log and RMAN
repository rather than assuming the backup succeeded.
If the database operates in NOARCHIVELOG mode, structural changes do not trigger that automatic autobackup. Use the approved explicit
backup procedure and ensure that a subsequent consistent database backup reflects the new structure.
Plan for Control-File Recovery
A restored backup control file represents the database structure and repository state at the time that backup was created. It may not contain records for data files, archived logs, or backup pieces created later. Recovery may need to catalog surviving backup pieces, register archived redo, rename files, or otherwise reconcile the restored metadata with the actual recovery assets.
Keep the DBID in the recovery runbook. If the target control file and recovery catalog are unavailable, RMAN may require SET DBID before
it can search for a control-file autobackup. If the environment uses a nondefault autobackup format, the runbook must also record that exact format and
the device configuration needed to reach it.
Do not publish one universal control-file restore script. The sequence depends on which SPFILE, control files, recovery catalog, backups, archived
redo logs, online redo logs, credentials, and encryption materials survived. Recovery with a backup or re-created control file commonly concludes
with OPEN RESETLOGS after the required recovery, but the DBA must follow the procedure appropriate to the actual failure.
Verify That the Backup Can Be Used
List control-file backups known to RMAN:
LIST BACKUP OF CONTROLFILE;Check that the expected explicit backups and autobackups appear, review RMAN job messages, and confirm the autobackup location and device type in the alert log. Crosscheck repository records against storage as required by the maintenance plan, and validate the relevant backup pieces.
Repository listings and successful job messages do not prove that the database can be recovered. Periodically test the disaster-recovery procedure in an isolated environment. A complete test should demonstrate that the team can retrieve or re-create the SPFILE, use the recorded DBID and format to find the control-file autobackup, restore and mount the control file, locate data file and archived redo backups, and continue database recovery.
Measure the elapsed recovery time and record any manual dependencies discovered during the test. A technically valid control-file backup can still fail the recovery-time objective if credentials, media libraries, network paths, encryption keys, or sufficient restore capacity are unavailable.
A resilient strategy therefore combines multiplexed current members, RMAN autobackups, intentional recovery copies, current documentation, and tested restoration. The next lesson shows how to monitor an open database backup.