Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
Include the recovery catalog database in your backup and recovery strategy. If you do not back up the recovery catalog and a disk failure occurs that destroys the recovery catalog database, then you may lose the metadata in the catalog. Without the recovery catalog contents, recovery of your other databases is likely to be more difficult.
Here are some general guidelines you should follow when developing a strategy for backing up the recovery catalog.
The recovery catalog database is a database like any other, and is also a key part of your backup and recovery strategy. Protect the recovery catalog as you would protect any other part of your database, by backing it up. The backup strategy for your recovery catalog database should be part of your overall backup and recovery strategy.
Back up the recovery catalog with the same frequency that you back up the target database. For example, if you make a weekly whole database backup of the target database, then back up the recovery catalog immediately after all target database backups, in order to protect the record of the whole database backup. This backup can help you in a disaster recovery scenario. Even if you have to restore the recovery catalog database using a control file autobackup, you can then use the full record of backups in your restored recovery catalog database to restore the target database without using a control file autobackup for the target database.
When backing up the recovery catalog database, you can use RMAN to make the backups. As illustrated in Figure 10-1, you should start RMAN with the NOCATALOG
option so that the repository for the recovery catalog is the control file in the catalog database.
Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database:
Run the recovery catalog database in ARCHIVELOG
mode so that you can do point-in-time recovery if needed.
Set the retention policy to a REDUNDANCY
value greater than 1
.
Back up the database onto two separate media (for example, disk and tape).
Run BACKUP
DATABASE
PLUS
ARCHIVELOG
at regular intervals, to a media manager if available, or just to disk.
Do not use another recovery catalog as the repository for the backups.
Configure the control file autobackup feature to ON
.
With this strategy, the control file autobackup feature ensures that the recovery catalog database can always be recovered, so long as the control file autobackup is available.
Figure 10-1 Using the Control File as the Repository for Backups of the Recovery Catalog
See Also:
"Performing Disaster Recovery" for more information for recovery with a control file autobackupNever store a recovery catalog containing the RMAN repository for a database in the same database as the target database or on the same disks as the target database. For example, do not store the catalog for database prod1
in prod1
. A recovery catalog for prod1
is only effective if it is separated from the data that it is designed to protect.
If prod1
suffers a total media failure, and if the recovery catalog for prod1
is also stored in prod1
, then if you lose the database you also lose the recovery catalog. At that point the only option is to restore an autobackup of the control file for prod1
and use it to restore and recover the database without the benefit of any information stored in the recovery catalog.
Separating the target and catalog databases is especially important when you back up a recovery catalog database. The following example shows what you should not do. For example, consider the following:
Target database prod1
and catalog database catdb
are on different hosts.
catdb
contains the recovery catalog repository for target database prod1
.
You decide to use a recovery catalog to back up catdb
, but are not sure where to create it. If you create the catalog containing the repository for catdb
in database catdb
, then if you lose catdb
due to a media failure, you will have difficulty restoring catdb
and will leave prod1
without a recovery catalog to use in a restore scenario.
Logical backups of the RMAN recovery catalog created with one of Oracle's export utilities can be a useful supplement for physical backups. In the event of damage to a recovery catalog database, you can quickly reimport the exported recovery catalog data into another database and rebuild the catalog this way.
Restoring and recovering the recovery catalog is much like restoring and recovering any other database, if you backed it up with RMAN.
You can restore the control file and SPFILE for the recovery catalog database from an autobackup, then restore and perform complete recovery on the rest of the database. The processes required are all described in Oracle Database Backup and Recovery Basics You can also use another recovery catalog to record metadata about backups of this recovery catalog database, if you are in a situation where you are using multiple recovery catalogs.
If the recovery catalog database is lost or damaged, and recovery of the recovery catalog database through the normal Oracle recovery procedures is not possible, then you must re-create the catalog. Examples of this worst-case scenario include:
A recovery catalog database that has never been backed up
A recovery catalog database that has been backed up, but cannot be recovered because the datafile backups or archived logs are not available
You have these options for partially re-creating the contents of the missing recovery catalog:
Use the RESYNC
CATALOG
command to update the recovery catalog with any RMAN repository information from the control file of the target database or a control file copy. Note that any metadata from control file records that aged out of the control file is lost.
Issue CATALOG START WITH...
commands to recatalog any available backups.
To minimize the likelihood of this worst-case scenario, your backup strategy should at least include backing up the recovery catalog using RMAN as described in "Backing Up the Recovery Catalog".
See Also:
Oracle Database Backup and Recovery Reference for information about the CATALOG
command
Oracle Database Backup and Recovery Reference for information about the CROSSCHECK
command
"Managing the Control File When You Use a Recovery Catalog" to learn about how records age out of the control file