8.1 Managing the RMAN Repository Using Only the Control File

The authoritative RMAN repository is always stored in the database control file. RMAN repository data can also be stored in one or more recovery catalog databases, as an adjunct to the information stored in the control file, and to provide a longer history of backups.

While RMAN is designed to work without a recovery catalog, if you choose not to use a recovery catalog, you must perform some additional administrative tasks.

8.1.1 Backing Up and Restoring the Control File

If you are not using a recovery catalog, the control file is the sole storage for the RMAN repository, so it is doubly important that you protect it. Maintain alternate control files through multiplexing or operating system mirroring, and back up the control file frequently.

Configure CONTROLFILE AUTOBACKUP to ON to ensure extra protection for your control file.

So long as a control file autobackup is available, RMAN can restore the SPFILE and backup control file, and mount the database. After the control file is mounted, you can restore the remainder of the database.

Note that, if you restore a control file from autobackup, any persistent settings you set with the CONFIGURE command will revert to the values they had at the time of the control file autobackup. You should review the settings with the SHOW ALL command after restoring the control file.

8.1.2 Monitoring the Overwriting of Control File Records

When you do not use a recovery catalog, the control file is the sole source of information about RMAN backups. As you make backups, Oracle records these backups in the control file. To prevent the control file from growing without bound to hold RMAN repository data, records can be reused if they are older than a threshhold you specify.

The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum age in days of a record before it can be overwritten:

CONTROL_FILE_RECORD_KEEP_TIME = integer

For example, if the parameter value is 14, then any record aged 14 days and older is a candidate for reuse. Information in an overwritten record is lost. The oldest record available for reuse will be used first.

When Oracle needs to add new RMAN repository records to the control file, but no record is older than the threshhold, Oracle attempts to expand the size of the control file. If the underlying operating system prevents the expansion of the control file (due to a disk full condition, for instance), Oracle overwrites the oldest record in the control file and logs this action in the alert log.

The default value of CONTROL_FILE_RECORD_KEEP_TIME is 7 days. If you are not using a recovery catalog, then set the CONTROL_FILE_RECORD_KEEP_TIME value to slightly longer than the oldest file that you need to keep. For example, if you back up the whole database once a week, then you need to keep every backup for at least seven days. Set CONTROL_FILE_RECORD_KEEP_TIME to a value such as 10 or 14.

Caution:

Regardless of whether you use a recovery catalog, never use RMAN when CONTROL_FILE_RECORD_KEEP_TIME is set to 0. If you do, then you may lose backup records.

8.1.2.1 Managing the Overwriting of Control File Records

Assume the following scenario:

You do not use a recovery catalog.
CONTROL_FILE_RECORD_KEEP_TIME is set to 14.
All records currently in the control file are between 1 and 13 days old.
The control file is at the maximum size permitted by the operating system.

You make a backup of the database. Because Oracle cannot expand the control file beyond the operating system file size limit, it begins overwriting records in the control file, starting with the oldest ones. For each record that it overwrites, it records an entry in the alert.log similar to the one shown here:

kccwnc: following control file record written over:  
RECID #72 Recno 72 Record timestamp  
07/28/00 22:15:21  
Thread=1 Seq#=3460  
Backup set key: stamp=372031415, count=17  
Low scn: 0x0000.3af33f36  
07/27/00 21:00:08  
Next scn: 0x0000.3af3871b  
07/27/00 23:23:54  
Resetlogs scn and time  
scn: 0x0000.00000001  
08/05/99 10:46:44  
Block count=102400 Blocksize=512

The most certain way to avoid this situation is to use a recovery catalog. If you cannot use a recovery catalog, then you can take the following measures to avoid problems associated with overwriting control file records:

Store the control file in a file system rather than raw disk, so that it can expand as needed.
Monitor the alert.log to make sure that Oracle is not overwriting control file records.

See Also:
Oracle Database Backup and Recovery Advanced User's Guide for a conceptual overview of control file records and how they are reused

8.1.2.2 Interaction of Flash Recovery Area and CONTROL_FILE_RECORD_KEEP_TIME

When a control file record containing information about a file created in the flash recovery area is about to be reused (because the record is older than CONTROL_FILE_RECORD_KEEP_TIME), if the file is eligible for deletion then the database attempts to delete the file from the flash recovery area. Otherwise, the database expands the size of the control file section containing the record for this file, logging the expansion in the alert log with a message like this example:

kccwnc: trying to expand control file section nnnn for Oracle Managed Files

where nnnn is the number of the control file record type.

If the control file is at the maximum size supported under the host operating system, then the database cannot expand the control file. In such a situation, this warning appears in the alert log:

WARNING: Oracle Managed File filename is unknown to control file. This is the result of limitation in control file size that could not keep all recovery area files.

This means that the control file cannot hold a record of all flash recovery area files needed to satisfy the configured retention policy.

There are several ways to avoid or alleviate this problem:

Use a control file of larger block size, preferably one with 32K block size. To achieve this, you must set the SYSTEM tablespace block size to be greater than or equal to the control file block size, and re-create the control file after changing DB_BLOCK_SIZE.
Make the files in the flash recovery area eligible for deletion, by backing them up to tertiary storage such as tape. For example, you can use the RMAN command BACKUP RECOVERY AREA to specifically back up files in the flash recovery area to your media manager.
Make more files in the flash recovery area eligible for deletion, by changing the retention policy to a shorter recovery window or lower degree of redundancy.