| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
The RMAN repository is the collection of metadata about the target databases that RMAN uses for backup, recovery, and maintenance. RMAN always stores this information in records in the control file. The version of this information in the control file is the authoritative record of RMAN's backups of your database. This is one reason why protecting your control file is a important part of your backup strategy. RMAN can conduct all necessary backup and recovery operations using just the control file to store the RMAN repository information, and maintains all records necessary to meet your configured retention policy.
You can also create a recovery catalog, an external Oracle database in which to store this information. The control file has finite space for records of backup activities, while a recovery catalog can store a much longer history. The added complexity of operating a recovery catalog database can be offset by the convenience of having the extended backup history available if you have to do a recovery that goes further back in time than the history in the control file.
There are also a few features of RMAN that only function when you use a recovery catalog. For example, RMAN stored scripts are stored in the recovery catalog, so commands related to them require the use of a recovery catalog. Other RMAN commands are specifically related to managing the recovery catalog and so are not available (and not needed) if RMAN is not connected to a recovery catalog.
The recovery catalog's version of the RMAN repository is maintained solely by RMAN. The target instance never accesses it directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file after any operation that updates the repository, and also before certain operations.
See Also:
Oracle Database Backup and Recovery Basics for details on how to manage the RMAN repository, and Chapter 10, "Managing the Recovery Catalog" to learn more about features specific to the recovery catalogBecause most information in the recovery catalog is also available in the target database's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery catalog. This mode is especially appropriate for small databases where installation and administration of a separate recovery catalog database is burdensome. The only RMAN feature that is not supported in NOCATALOG mode is stored scripts.
When you do not use a recovery catalog, the control file is the exclusive source of information about backups and copies as well as other relevant information. The control file contains two types of records: circular reuse records and noncircular reuse records.
Circular reuse records contain noncritical information that is eligible to be overwritten if the need arises. These records contain information that is continually generated by the database. Circular reuse records are arranged in a logical ring. When all available record slots are full, the database either expands the control file to make room for a new record or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.
See Also:
Oracle Database Backup and Recovery Basics to learn how to manage the handling of circular reuse recordsTo make it easier to restore and recover the database without using a recovery catalog, Oracle recommends that you:
Enable the control file autobackup feature, which causes RMAN to automatically back up the control file, and also enables RMAN to restore the control file autobackup without access to a repository
Keep a record of your DBID, which you may need to recover your database in the event that you lose your control file
Use a minimum of two multiplexed or mirrored control files on separate disks
Keep all Recovery Manager backup logs.
If you lose the current control files, then you can restore a control file autobackup even if you do not use a recovery catalog.
See Also:
"Control File and Server Parameter File Autobackups" to learn about disaster recovery using control file autobackupsIt is recommended that you store the recovery catalog in a dedicated database. If you store the recovery catalog alongside other data in some other database, then if you lose that other database you will lose your recovery catalog as well. This will make your recovery more difficult.
The enrolling of a database in a recovery catalog is called registration. You can register more than one target database in the same recovery catalog. For example, you can register databases prod1, prod2, and prod3 in a single catalog owned by catowner in the database catdb. Because RMAN distinguishes databases by unique database identifier (DBID), each database registered in a given catalog must have a unique DBID.
See Also:
"Registering a Database in the Recovery Catalog", and Oracle Database Utilities to learn how to use the DBNEWID utility to change the DBID of a databaseThe recovery catalog contains information about RMAN operations, including:
Datafile and archived redo log backup sets and backup pieces
Datafile copies
Archived redo logs and their copies
Tablespaces and datafiles on the target database
Stored scripts, which are named user-created sequences of RMAN commands
Persistent RMAN configuration settings
The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current. Resynchronizations can be full or partial.
See Also:
"Types of Records in the Control File" for more information about control file records, and "When to Resynchronize the Recovery Catalog" for rules on when to resynchronizeRMAN creates a snapshot control file, which is a temporary backup control file, in an operating system specific location each time it performs a full resynchronization. This snapshot control file ensures that RMAN has a consistent view of the control file. Because the snapshot control file is intended for RMAN's short-term use, it is not registered in the recovery catalog. RMAN records the snapshot control file checkpoint in the recovery catalog to indicate the currency of the recovery catalog.
The database server ensures that only one RMAN session accesses a snapshot control file at any point in time. This safeguard is necessary to ensure that two RMAN sessions do not interfere with each other's use of the snapshot control file.
Note:
You can specify the name and location of the snapshot control file. For instructions, refer to "Setting the Snapshot Control File Location".See Also:
"Managing the Control File When You Use a Recovery Catalog" to learn how to resynchronize the recovery catalog, and Oracle Database Backup and Recovery Reference for syntaxA single recovery catalog is able to store information for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently.
If the recovery catalog is destroyed and no backups of it are available, then you can partially reconstruct the catalog from the current control file or control file backups. Nevertheless, you should always aim to have a valid, recent backup of the catalog.
See Also:
"Backing Up the Recovery Catalog" to learn how to back up the recovery catalogWhen you use RMAN with a recovery catalog in an environment where you have run past versions of the database, you can wind up with versions of the RMAN client, recovery catalog database, recovery catalog schema, and target database that all originated in different releases of the database. You will find a compatibility matrix in Oracle Database Backup and Recovery Reference that describes supported interoperability scenarios.
