Oracle Database : Control File Multiplexing on ASM and Filesystem

Oracle DBA Control File Multiplexing ASM RMAN High Availability Oracle 19c

The control file is a small binary file that records the physical structure of the database: datafile and redo log locations, the database name, checkpoint information and RMAN backup metadata. The database cannot mount without it.

If the database has only one control file and that file is lost or corrupted, the instance stops and the control file must be restored from backup. Multiplexing keeps two or more identical copies on different disks or disk groups. Oracle writes to all copies at the same time, so losing one copy does not mean losing the database.

This guide shows how to add a control file copy for databases on ASM and on a filesystem.

Note: All names and paths in this guide, such as ORCL, +DATA, +RECO and /u02/oradata, are examples. Replace them with the values from your environment.

Downtime Required: Adding a control file copy requires a database restart. Plan the change in a maintenance window.

Prerequisites

• The new location is on a different disk or disk group from the existing control file. Two copies on the same disk do not protect against a disk failure.
• The database uses an SPFILE. If it uses a PFILE, edit the control_files line in the PFILE instead of using ALTER SYSTEM.
• For a filesystem, the target directory exists and is owned by the oracle user.

Step 1: Check the Current Control Files

SQL> SHOW PARAMETER control_files

SQL> SELECT NAME, STATUS FROM V$CONTROLFILE;

Note the full path of every existing control file. You will need it in the following steps.

Step 2: Back Up the SPFILE as a PFILE

Create a text copy of the current parameters. If the instance fails to start after the change, this PFILE is the quickest way back.

SQL> CREATE PFILE='/home/oracle/pfile_backup_before_ctl.ora' FROM SPFILE;

Step 3: Back Up the Control File

$ rman target /

RMAN> BACKUP CURRENT CONTROLFILE
      FORMAT '/u01/backup/rman/CTL_%d_%T_%U.bkp'
      TAG 'CTL_BEFORE_MULTIPLEX';

Part A: Multiplex Control Files on ASM

On ASM, control files cannot be copied with OS commands. RMAN restores a copy from the existing control file into the new disk group.

Step 4: Add the New Disk Group to CONTROL_FILES

Set the parameter to the existing control file plus the new disk group. Specify only the disk group name for the new copy; ASM generates the file name.

SQL> ALTER SYSTEM SET control_files=
     '+RECO/ORCL/CONTROLFILE/current.256.1175762253',
     '+DATA'
     SCOPE=SPFILE;

Step 5: Shut Down the Database

SQL> SHUTDOWN IMMEDIATE;

Step 6: Start in NOMOUNT and Restore the Control File

$ rman target /

RMAN> STARTUP NOMOUNT;

RMAN> RESTORE CONTROLFILE FROM '+RECO/ORCL/CONTROLFILE/current.256.1175762253';

RMAN reads the existing control file and writes it to every location in control_files, creating the new copy in +DATA.

Step 7: Mount and Open the Database

RMAN> ALTER DATABASE MOUNT;

RMAN> ALTER DATABASE OPEN;

Note: Because the control file was restored from the current, cleanly closed control file, the database opens normally.

Step 8: Verify

SQL> SHOW PARAMETER control_files

SQL> SELECT NAME, STATUS FROM V$CONTROLFILE;

Both control files should be listed with an empty STATUS.

Note: When the SPFILE is used, RMAN automatically replaces '+DATA' in control_files with the full ASM file name it created, such as +DATA/ORCL/CONTROLFILE/current.270.1175799013. If the parameter still shows only '+DATA', set it manually to the full names from V$CONTROLFILE with SCOPE=SPFILE.

Part B: Multiplex Control Files on a Filesystem

On a filesystem, the new copy is created with a simple OS copy while the database is shut down.

Step 4: Add the New Path to CONTROL_FILES

SQL> ALTER SYSTEM SET control_files=
     '/u01/app/oracle/oradata/ORCL/control01.ctl',
     '/u02/oradata/ORCL/control02.ctl'
     SCOPE=SPFILE;

Step 5: Shut Down the Database

SQL> SHUTDOWN IMMEDIATE;

Important: Always use SHUTDOWN IMMEDIATE or SHUTDOWN NORMAL. Never copy a control file after SHUTDOWN ABORT or while the database is running, because the copy will be inconsistent.

Step 6: Copy the Control File at OS Level

$ mkdir -p /u02/oradata/ORCL

$ cp /u01/app/oracle/oradata/ORCL/control01.ctl /u02/oradata/ORCL/control02.ctl

$ ls -l /u02/oradata/ORCL/control02.ctl

Confirm that the new file is owned by the oracle user and has the same size as the original.

Step 7: Start the Database

SQL> STARTUP;

Step 8: Verify

SQL> SHOW PARAMETER control_files

SQL> SELECT NAME, STATUS FROM V$CONTROLFILE;

Alternative: Instead of cp, the RMAN method from Part A also works on a filesystem: STARTUP NOMOUNT, then RESTORE CONTROLFILE FROM '/u01/app/oracle/oradata/ORCL/control01.ctl';.

RAC Databases

In RAC, the control files are shared by all instances. Stop the whole database with srvctl, perform the restore from one node, then start the database again:

$ srvctl stop database -d ORCL

SQL> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM '+RECO/ORCL/CONTROLFILE/current.256.1175762253';
SQL> SHUTDOWN IMMEDIATE;

$ srvctl start database -d ORCL

Rollback: If the Database Does Not Start

If the instance fails to start because of a wrong path in control_files, start it with the PFILE backed up in Step 2 and recreate the SPFILE:

SQL> STARTUP NOMOUNT PFILE='/home/oracle/pfile_backup_before_ctl.ora';

SQL> CREATE SPFILE FROM PFILE='/home/oracle/pfile_backup_before_ctl.ora';

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP;

ASM: If the SPFILE is stored in ASM, use CREATE SPFILE='+DATA/ORCL/PARAMETERFILE/spfileORCL.ora' FROM PFILE='...'; so it is recreated in the location referenced by the database configuration.

Best Practices

• Keep at least two control file copies, and three for critical databases.
• On ASM, place copies in different disk groups, such as +DATA and +RECO.
• On a filesystem, place copies on different physical disks or mount points, not just different directories.
• Enable CONFIGURE CONTROLFILE AUTOBACKUP ON in RMAN. Multiplexing protects against losing a disk; backups protect against logical errors and losing every copy.
• Update your documentation and monitoring with the new control file locations.

Quick Reference

Step	ASM	Filesystem
Set parameter	control_files='<existing>','+DATA'	control_files='<existing>','<new path>'
Shut down	SHUTDOWN IMMEDIATE	SHUTDOWN IMMEDIATE
Create copy	STARTUP NOMOUNT + RESTORE CONTROLFILE FROM	cp at OS level
Start	ALTER DATABASE MOUNT + OPEN	STARTUP
Verify	V$CONTROLFILE and SHOW PARAMETER control_files

Summary

Control file multiplexing is a simple change that removes a single point of failure. On ASM, set control_files to include the new disk group and let RMAN restore the copy from the existing control file. On a filesystem, shut down cleanly, copy the file with cp and start the database.

In both cases, back up the SPFILE and control file first, verify both copies in V$CONTROLFILE afterwards, and keep RMAN controlfile autobackup enabled.

Key Takeaway: Multiplexing protects against losing a disk, and RMAN backups protect against losing everything else. A production database needs both.