Resynchronization Occurrences

A resynchronization will cause Recovery Manager to compare the control file information with a control file. Any changes in the control file may cause one or more records in the recovery catalog to be updated. This will ensure that the log history and backup history records are correctly reflected in the recovery catalog. Log switch records are created when a log switch occurs. Recovery Manager needs to keep track of this information to identify any archive log files correctly. When you archive an online log or restore an archived log backup set, you are creating an archived log. If you need to restore using an archived log, Recovery Manager will have to know the location of the log.

Backup history records are associated with backup sets, backup pieces, backup set members, and file copies. You need to resynchronize if you issue a backup or copy command and the recovery catalog is not available.

Physical schema records are associated with data files and tablespaces. You should use the resynch command whenever you change the values in the control files associated with these records. If Recovery Manager is connected to the recovery catalog, it will automatically perform a resynchronization before and after as part of any backup, restore, or recovery command done through RMAN. If your target database is open during a resynchronization, a new consistency point will be created. In the next lesson, you will learn how to use the change command.

When RMAN uses a recovery catalog, it uses a resynchronization process to ensure that the recovery catalog is consistent with the target database control file. Generally, Oracle performs database resynchronization itself after RMAN operations such as backups and recoveries, so you really do not need to resync the recovery catalog often. One example of the need to resync the recovery catalog is if you are running backups sometimes with and sometimes without a recovery catalog. To manually get Oracle to resync the recovery catalog, use the resync catalog command:

resync catalog;

When Oracle synchronizes the recovery catalog, it first creates a snapshot control file and compares it with the recovery catalog. Once that comparison is complete, Oracle will update the recovery catalog so it is in sync with the database control file.

In earlier versions of RMAN (In Oracle 9i and earlier), the recovery catalog records were not purged at all and as a result the recovery catalog would get quite large. Even in later versions of the Oracle Database there were cases where the recovery catalog would get out of sync with the database control file and certain records would not be deleted. Also, there have been bugs in the past that would cause certain tables in the recovery catalog not to have deleted records removed from them. These problems have largely been solved for some time, and in most cases there should be no reason to manually need to purge recovery catalog records at all. If you find that the recovery catalog is growing uncontrollably, you probably need to make sure that you are managing your retention correctly. If you are only using an (FRA) Fast Recovery Area, then RMAN should manage the retention for you quite well and you should not see any divergence in the recovery catalog. If you do, you may well have hit a bug and you should report this to Oracle Support.
In cases where your backups are being moved to a second or third tier that is not on the FRA, you will need to manually manage the retention of these RMAN files and the metadata associated with them. This requires the use of the delete obsolete command to remove obsolete backups and also the use of the crosscheck command to ensure that nothing has removed the physical files from the backup media, leaving orphan metadata records in the recovery catalog.
Do keep an eye on the growth of the recovery catalog because performance of the catalog can be impacted by uncontrolled growth. The recovery catalog will maintain old incarnation records forever. These records can be found in the RC_DATABASE_INCARNATION view, which is based on the underlying recovery catalog table DBINC. It is rare to need to remove old incarnation records from the recovery catalog. However, you can use the delete SQL command to remove incarnation information from the DBINC table if you need to. We would strongly suggest you open a support ticket with Oracle before you do this, however.

Click the Quiz link below to test your understanding of the register, resynch, and reset commands of RMAN.
Register Resynch Reset - Quiz