The control file is a relatively small (in the megabyte range) binary file that contains the datafiles and redo log files (that constitute a database). The control file is created when the database is created and is updated with the physical changes, for example, whenever a datafile is added or renamed.
The control file is updated continuously and should be available at all times. Don’t edit the contents of the control file; only Oracle processes should update its contents. When the database is started, Oracle uses the control file to identify the datafiles and redo log files and opens them. Control files play a major role when recovering a database.
Recovery Manager (RMAN) is the Oracle utility you use to back up and recover databases.
The control file size is determined by the MAX that are provided when the database is created:
Any structural change such as adding or renaming a file, the information is immediately recorded in the Control file. The Control file does not change and is already preallocated by Oracle.
Back up the control file after any structural changes. Updation of information in control file is done as follows:
The control file contains two types of record sections: reusable and not reusable. RMAN information is kept in the reusable section. Items such as the names of the backup datafiles are kept in this section, and once this section fills up, the entries are reused in a circular fashion after the number of days specified by the initialization parameter CONTROL_FILE_RECORD_KEEP_ TIME is reached.
Because the control file is critical for database operation, at a minimum have two copies of the control file; Oracle recommends a minimum of three copies. It is recommended to duplicate the control file on different disks either by using the multiplexing feature of Oracle or by using the mirroring feature of your operating system.
If DBCA was used to create database, three copies of the control files are multiplexed by default.
Multiplexing means keeping a copy of the same control file or other file on different disk drives. Copying the control file to multiple locations and changing the CONTROL_FILES parameter in the text-based initialization file init.ora to include all control file names specifies the multiplexing of the control file. The following syntax shows three multiplexed control files.
CONTROL_FILES = (‘/ora01/oradata/MYDB/ctrlMYDB01.ctl’,
If one control file is lost, the database can be restarted after copying one of the other control files or after changing the CONTROL_FILES parameter in the initialization file.
When multiplexing control files, Oracle updates all the control files at the same time, but uses only the first control file listed in the CONTROL_FILES parameter for reading.
When creating a database, control file names can be listed in the CONTROL_FILES parameter, and Oracle creates as many control files as are listed. A database can have maximum of eight multiplexed control file copies.
The above steps are to be followed to add, rename, or delete control files. shut down the database use the operating system copy command (copy, rename, or delete the file) modify the init.ora parameter file and start up the database.
Multiplexing using a binary SPFILE is similar to multiplexing using init.ora. The major difference is in how the CONTROL_FILES parameter is changed.
Follow these steps:
The checkpoint background process controls the amount of time required for instance recovery. During a checkpoint, CKPT updates the control file and the header of the number (SCN). The SCN, which is a number sequentially assigned to each transaction in the database, is also recorded in the control file against the datafile name that is taken offline or made read-only.
A checkpoint occurs automatically every time a redo log file switch occurs, either when the current redo log file fills up or when you manually switch redo log files. The DBWn processes in conjunction with CKPT routinely write new and changed buffers to advance the checkpoint from where instance recovery can begin, thus reducing the MTTR.
A redo log file records all changes to the database, in most cases before the changes are written to the datafiles.
To recover from an instance or a media failure, redo log information is required to roll datafiles forward to the last committed transaction. Ensuring that you have at least two members for each redo log file group dramatically reduces the likelihood of data loss because the database continues to operate if one member of a redo log file is lost.