| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
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 autobackup |
Never 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:
|
