Control File Maintenance in Oracle AI Database 26ai

A control file records the database identity, datafile and redo log locations, checkpoint information, and recovery metadata. Oracle needs this information to mount the database and determine how its physical files fit together. In a multitenant database, control files belong to the container database (CDB). Pluggable databases (PDBs) share them.

Maintenance begins by identifying what remains usable. Adding another current copy, restoring an older backup, and reconstructing a control file from SQL are different operations. Choosing the appropriate method preserves available metadata and determines whether media recovery and RESETLOGS are necessary.

Choose the appropriate maintenance operation

Maintain at least two active copies on separate physical disks or independent storage failure domains. Different drive letters alone do not establish separation. Oracle updates the configured copies during operation, but losing a member can still interrupt the instance. Multiplexing provides surviving recovery material; backups preserve earlier recoverable states. Oracle describes these distinctions in Managing Control Files.

The relationship between the files explains the maintenance sequence. During startup, Oracle reads initialization parameters before mounting the database through its control files. The control file identifies datafiles and redo needed for subsequent operations. A correct SPFILE entry cannot compensate for a missing physical control file, and a correctly copied file remains unused until the active configuration includes its path.

Inspect the database and its parameter source

The following example uses a single-instance CDB, an SPFILE, and manually named Windows filesystem files. Connect to the intended database through SQL*Plus as an authorized SYSDBA. Confirm that the current container is CDB$ROOT and record the configuration:

CONNECT / AS SYSDBA
SHOW CON_NAME
SHOW PARAMETER spfile
SHOW PARAMETER control_files

SELECT name, dbid, log_mode, force_logging
FROM v$database;

SELECT name FROM v$controlfile ORDER BY name;
SHOW PDBS

A populated spfile value identifies the server parameter file used at startup. An empty value indicates text-PFILE startup, which requires the alternative procedure below. Record existing control-file locations and the PDB open states the application requires.

CONTROL_FILES is a static parameter. With SPFILE startup, change it using ALTER SYSTEM and SCOPE=SPFILE; the saved setting takes effect at the next startup. The change does not create a physical file. A binary SPFILE must be managed through supported commands rather than edited as text. See the parameter reference and ALTER SYSTEM documentation.

Adding a second control file

When the instance uses a text PFILE

Shut down, copy the current control file while stopped, and edit the text initialization file actually used at startup. Retain the complete list:

control_files = ('D:\oradata\CDB1\control01.ctl',
                 'E:\oradata\CDB1\control02.ctl')

Restart explicitly with that PFILE, substituting its actual location for this example:

STARTUP PFILE='D:\oracle\admin\CDB1\pfile\initCDB1.ora'

Verify the paths and PDB states as above. A small PFILE containing only an SPFILE=... pointer still directs startup to a binary SPFILE; inspect the actual startup arrangement before choosing how to change parameters.

Moving or retiring an existing location

Moving a copy replaces one configured path while retaining the other active members. Building on the previous example, move the E: copy to F: while keeping the D: file. Before shutdown, save:

ALTER SYSTEM SET CONTROL_FILES =
  'D:\oradata\CDB1\control01.ctl',
  'F:\oradata\CDB1\control02.ctl'
  SCOPE=SPFILE;

Shut down the instance, then copy the current E: file to the prepared, unused F: destination. Apply the same existence, permissions, and offline hash checks used when adding a copy. The PowerShell copy command is:

Copy-Item -LiteralPath 'E:\oradata\CDB1\control02.ctl' -Destination 'F:\oradata\CDB1\control02.ctl'

Restart and verify that V$CONTROLFILE lists D: and F:. Keep the old file through verification, then retire it according to the maintenance plan. Removing a path from CONTROL_FILES does not delete the operating-system file. Once Oracle resumes updating the active members, the retired copy becomes stale.

ALTER DATABASE RENAME FILE does not relocate control files. Their locations come from the initialization parameter. Routine relocation also does not require CREATE CONTROLFILE or RESETLOGS.

If a failed path prevents mounting, an instance can start in NOMOUNT to change the SPFILE setting. Another shutdown and startup is then needed to load that static change. This is useful during an incident, rather than an extra cycle required for every planned move.

When one current copy survives and other database files are intact, repair or relocate the failed member while stopped, then restart without media recovery solely for that control-file loss. Any temporary reduction in the number of copies should be followed by restoring multiplexed protection.

Protecting the control file and its recovery metadata

An RMAN control-file backup preserves binary recovery information. A trace script records SQL for reconstruction. Keep both for their respective purposes. At the RMAN prompt, connected to the target CDB root with appropriate backup privileges, inspect autobackups and create explicit backups:

Active copies and backups protect different points in time. An additional active member receives subsequent database changes along with the original. A retained backup preserves the information recorded when that backup was taken. Keeping both helps address physical file loss while retaining historical recovery material. Record the DBID and backup locations outside the database so that losing its control files does not also remove the information needed to find their backups.

SHOW CONTROLFILE AUTOBACKUP;
BACKUP CURRENT CONTROLFILE;
BACKUP SPFILE;

The SPFILE command assumes SPFILE startup. Control-file autobackups are enabled by default for CDBs, but verify the actual configuration and availability of usable backups. Review protection after structural changes such as adding datafiles or redo log groups. Oracle explains the settings in Configuring the RMAN Environment.

Generate and locate a reconstruction trace

While the CDB is mounted or open, run the following in one SQL*Plus session:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

SELECT name, value
FROM v$diag_info
WHERE name IN ('Diag Trace', 'Default Trace File');

The default output is stored in the Automatic Diagnostic Repository (ADR). Diag Trace identifies the directory, and Default Trace File identifies the current process's trace file. The alert log can also identify the generated file. Use these reported locations instead of assuming an installation-specific trace directory. See Oracle's diagnostic-file guidance.

The trace contains CREATE CONTROLFILE and related recovery statements. Without an explicit RESETLOGS or NORESETLOGS choice during trace generation, Oracle provides both alternatives for later review. Creating this text does not recreate the control file, reset logs, or delete recovery records.

A reconstructed control file may lack historical RMAN records and archived-log information retained by a binary backup. Missing repository metadata is different from deleted backup files. Recovery may require reconciling available backups with the repository. Oracle's control-file backup documentation explains what the two backup forms preserve.

Restoring a backup control file

If every current copy is unusable and a usable backup exists, restore the backup rather than manually rebuilding its contents. The RMAN procedure prepares the instance in NOMOUNT, restores the control file, mounts the database, recovers it, and opens with RESETLOGS after successful recovery. In this backup-control-file recovery path, RECOVER is required even when no datafiles were restored.

Backup selection depends on the recorded DBID, recovery-catalog availability, backup format, and necessary channels. An autobackup search must have the correct context. If the backup-piece handle is known, it can identify the source directly. Follow the applicable RMAN backup-control-file recovery procedure, including available redo and any missing repository information.

This differs from copying a surviving current member: an older backup can lag behind the database's current structure and recovery history. Restoring it alone does not establish that the database is ready to open.

Recreating a control file from SQL

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

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

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

ALTER DATABASE OPEN;

ALTER DATABASE OPEN RESETLOGS;

Verify the result and account for the environment

For an addition or move, confirm the live paths, successful startup, and required PDB states. After restoration or reconstruction, also inspect recovery output and the alert log, reconcile file inventories, verify application access, and restore backup and repository protection. Investigate MISSINGnnnn entries according to the original file state and recovery history; neither unconditional renaming nor dropping a tablespace is a general repair.

Retain the before-and-after configuration with the maintenance record. It should identify the source and destination files, successful copy verification, the paths reported after restart, and any PDB state changes. This record makes the next maintenance operation easier to assess and helps distinguish retired files from the copies Oracle currently maintains.

For ASM, use documented storage-specific operations rather than filesystem copy commands. Changing Oracle Managed Files destination parameters does not relocate existing files. RAC requires shared accessible control-file storage, consistent parameter lists, and coordinated instance management. Data Guard requires role-specific recovery planning. These environments retain the same maintenance principles but need procedures matched to their storage and startup configuration.

The next lesson examines redo log files, which record the changes needed to recover the datafiles whose locations and recovery state are tracked in the control file.

Control File Maintenance - Exercise