Database Control File

The control file is a small binary file that records the physical structure of your database: the database name, the names and locations of every data file and online redo log file, the database's creation timestamp, checkpoint information, and the current log sequence number. It is created along with the database and must be writable whenever the database is open. This hasn't changed in Oracle AI Database 26ai; nothing about vector search, Select AI, or any of 26ai's other additions recasts what a control file is or does. It's still the compact map the instance needs before it can mount and open the database at all.

Without a usable control file, the instance cannot mount the database, and recovery becomes far more difficult. The reverse isn't quite as clean-cut, though: an instance opening successfully tells you the control file was usable, not necessarily that it's fully up to date. A stale or backup control file can still let a database open while requiring RESETLOGS or additional recovery afterward to be fully consistent, a distinction that matters more once you're relying on the control file during an actual recovery rather than just confirming the database is up.

Because losing your only good control file makes recovery so much harder, Oracle's standing recommendation is to keep multiple copies, each stored on a separate physical disk (or equivalent failure domain), and to back them up regularly. This lesson covers what the control file actually contains and how multiplexing, backups, and recreation work; the next lesson covers ongoing control file maintenance.

A control file's contents fall into a handful of well-defined categories:

• The database name, its unique identifier (DBID), and its creation timestamp
• The names and locations of every associated data file and online redo log file
• The current log sequence number and checkpoint information for each data file and redo log
• Log history and archived redo log information
• RMAN backup set, backup piece, and restore point metadata, when you aren't using a separate recovery catalog

Oracle actually organizes this internally into a larger number of distinct record sections, viewable through the V$CONTROLFILE_RECORD_SECTION dynamic performance view, but the exact count isn't something worth memorizing or testing yourself on. What matters practically is that all of this is binary data; you can't open a control file in a text editor and expect to read or edit it directly. Everything you'd want from it comes through querying the database or through Oracle's own control file utilities, covered below.

In a multitenant database, the control file belongs to the CDB as a whole. A CDB has one logical control file (multiplexed identical copies are expected and encouraged); individual PDBs don't maintain their own separate control files.

In Oracle RAC, every instance in the cluster shares the same control file or files, which must live on shared storage all instances can reach. DBCA typically configures two copies on that shared storage for redundancy. If any listed copy becomes unusable, from any instance's perspective, that instance fails when it tries to access the missing copy.

Control file locations are set with the CONTROL_FILES initialization parameter, which accepts multiple filenames. At startup, the instance opens every listed file and writes to all of them during normal operation; it reads from the first file in the list. If you don't set CONTROL_FILES before running CREATE DATABASE, the behavior depends on your setup: without Oracle Managed Files, the database falls back to an OS-specific default name; with OMF enabled, DB_CREATE_FILE_DEST and related parameters determine the name and location instead; and with ASM, incomplete ASM file names in DB_CREATE_FILE_DEST or DB_RECOVERY_FILE_DEST lead ASM to create the control files automatically. ASM tracks control files under its own CONTROLFILE file type, and in normal or high redundancy disk groups typically mirrors them more heavily than ordinary data files.

Multiplexing across separate physical disks is the primary protection against a single disk failure taking out your only control file. A common, practical pattern is to place a control file copy on each disk that already holds a multiplexed redo log member, so that losing one disk doesn't simultaneously cost you a control file and an entire redo log group.

A control file's size is driven mainly by the structural limits set when the database (or a new control file) was created: MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, and MAXINSTANCES. Raising any of these grows the control file to accommodate more entries. The data file section specifically can also grow automatically if you add files beyond MAXDATAFILES, as long as you stay within the separate DB_FILES limit.

The CONTROL_FILE_RECORD_KEEP_TIME parameter, seven days by default, controls how long reusable circular records, RMAN backup metadata and restore points among them, stay in the control file before they're eligible to be overwritten, relevant mainly if you aren't using a recovery catalog to hold that history separately.

The initial control file (or files) is created automatically by CREATE DATABASE. To add a new multiplexed copy, or to rename or relocate an existing one:

1. Shut down the database, so the file can't change while you're copying it.
2. Copy an existing control file using operating system commands.
3. Update the CONTROL_FILES parameter in the parameter file, or in the SPFILE after the next restart, to include the new location.
4. Restart the instance.

CONTROLFILE REUSE is a narrower option, useful only when you're recreating a database over existing files of a compatible size rather than adding a genuinely new copy.

CREATE CONTROLFILE is a last resort: use it when every control file copy is gone and no backup exists, or when you specifically need to raise one of the structural limits covered above. Take a full backup first if at all possible. The database must not be mounted when you run it, and it requires SYSDBA or SYSBACKUP privileges. Afterward you typically mount, recover if needed, and open the database, often with RESETLOGS if the existing redo logs can't be reused as is. Changing the database's name with this same statement also forces a RESETLOGS; if renaming is all you actually need, DBNEWID is the more targeted tool.

ALTER DATABASE BACKUP CONTROLFILE TO TRACE is the standard way to generate a ready-to-edit CREATE CONTROLFILE script from a database that's still healthy, worth running proactively rather than only after something has already gone wrong.

Back up the control file when the database is first created, and again after any change to its physical structure: adding, dropping, or renaming a data file, tablespace, or redo log group, or changing a tablespace between read-only and read-write. Your options:

• ALTER DATABASE BACKUP CONTROLFILE TO 'filename', a binary copy that includes archived log history, offline ranges, and RMAN backup records, information the trace-file version below doesn't capture.
• ALTER DATABASE BACKUP CONTROLFILE TO TRACE, a human-readable text script.
• RMAN, which can autobackup the control file alongside the SPFILE as part of your regular database backups.

A healthy, current, multiplexed copy can often simply replace a damaged one with no media recovery required at all. When the current control file is lost or inconsistent instead, a backup control file is used with USING BACKUP CONTROLFILE during recovery. If you're relying on the control file itself as your RMAN repository, meaning you aren't using a separate recovery catalog, protecting it well matters even more, since it's carrying backup metadata that a recovery catalog would otherwise hold independently.

A few dynamic performance views are worth knowing for day to day work with control files: V$CONTROLFILE lists the name and status of every copy the instance knows about, V$DATABASE reports whether the control file currently in use is a current file or a backup, along with the database's creation time, and V$CONTROLFILE_RECORD_SECTION shows the internal record types and how they get reused over time. None of this changes with 26ai's newer capabilities; a database hosting vector search, JSON, graph, or in-database agent workloads still depends on exactly the same mount, open, and recovery path the control file has always provided. Multiplex it, back it up after every structural change, and keep it consistent across every RAC instance, the same discipline that has applied for a long time now.

The next lesson covers control file maintenance in more depth.