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.
See Also:Oracle Database Administrator's Guide for a conceptual overview of the control file and more details about managing control files.
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.
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.
"Backing Up Control Files with RMAN" to learn about manual and automatic control file backups
Oracle Database Backup and Recovery Advanced User's Guide to learn how to restore a database when the current control file and recovery catalog are unavailable
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.
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
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.
Assume the following scenario:
You do not use a recovery catalog.
CONTROL_FILE_RECORD_KEEP_TIME is set to
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.
See Also:Oracle Database Backup and Recovery Advanced User's Guide for a conceptual overview of control file records and how they are reused
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
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
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.