RMAN requires a read-consistent view of the control file for the following tasks:
• Synchronizing with the recovery catalog
• Backing up the current control file
RMAN creates a snapshot copy of the current control file that it uses as a read-consistent copy while it is performing these tasks. This ensures that RMAN is working from a copy of the control file that is not being modified.
The default location of the snapshot control file is OS specific. On Linux platforms the default location/format is $ORACLE_HOME/dbs/[email protected]. Note that the default location is not in the FRA.
You can display the current snapshot control file details using the SHOW command:
RMAN> show snapshot controlfile name; CONFIGURE SNAPSHOT CONTROLFILE NAME TO
‘/ora01/app/oracle/product/23.1.0.1/db23c/dbs/snapcf_db23c.f’; # default
Use a Recovery Catalog
RMAN always stores its latest backup operations in the target database control file. You can set up an optional recovery catalog to store metadata regarding RMAN backups.
The recovery catalog is a separate schema (usually in a database different from that of the target database) that contains database objects (tables, indexes, and so on) that store the RMAN backup information.
The recovery catalog does not store RMAN backup pieces, only backup metadata.
The main advantages of using a recovery catalog are as follows:
• Provides a secondary repository for RMAN metadata. If you lose all your control files and backups of your control files, you can still retrieve RMAN metadata from the recovery catalog.
• Stores RMAN metadata for a much longer period than is possible when you just use a control file for the repository.
• Offers access to all RMAN features. Some restore and recovery features are simpler when using a recovery catalog.
The disadvantage of using a recovery catalog is that this is another database you have to set up, maintain, and back up.
Additionally, when you start a backup and attempt to connect to the recovery catalog, if the recovery catalog is not available for any reason (server down, network issues, and so on), you can continue with the backup without a recovery catalog.
You must also be aware of versioning aspects when using a recovery catalog. You need to make sure the version of the database you use to store the recovery catalog is compatible with the version of the target database. When you upgrade a target database, be sure the recovery catalog is upgraded (if necessary).
Configure RMAN’s Backup Retention Policy
RMAN retention policies allow you to specify how long you want to retain backups. RMAN has two mutually exclusive methods of specifying a retention policy:
• Recovery window
• Number of backups (redundancy)
With a recovery window, you specify a number of days in the past for which you want to be able to recover to any point in that window.
For example, if you specify a retention policy window of five days, then RMAN does not mark as obsolete backups of data files and archivelogs that are required to be able to restore to any point in that five-day window:
RMAN> configure retention policy to recovery window of 5 days;
You can also specify that RMAN keep a minimum number of backups. For instance, if redundancy is set to 2, then RMAN does not mark as obsolete the latest two backups of data files and archivelog files:
RMAN> configure retention policy to redundancy 2;
