RMAN Described

RMAN is an Oracle utility that can back up, restore, and recover database files. It is a feature of the Oracle database server and does not require separate installation. The Oracle Enterprise Manager Backup Management wizards and property sheets provide a graphical user interface to Recovery Manager. This chapter describes how to use Oracle Enterprise Manager to administer your database backup and recovery environment.

Recovery Manager uses database server sessions to perform the work of backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database.

Possible components of the RMAN environment are listed below

• RMAN executable
• Target database
• Oracle Enterprise Manager
• Recovery catalog database
• Recovery catalog schema
• Standby database
• Media management application
• Media management catalog

Of these components, only the RMAN executable and target database are required. RMAN automatically stores its metadata in the target database control file, so the recovery catalog database is optional. Nevertheless, maintaining a recovery catalog is strongly encouraged. If you create a catalog on a separate machine, and if the production machine fails completely, then you have all the restore and recovery information you need in the catalog. Possible configuration:

• One client node runs the RMAN executable
• One server node hosts the target database and media management subsystem
• One server node hosts the duplicate or standby database
• One server node hosts the recovery catalog database
• One client node runs the Oracle Enterprise Manager application, which provides a GUI interface to the databases in the system

In this scenario, you can run the RMAN executable from a client machine, and then connect to the target, catalog, and auxiliary databases. You can then run backup and recovery jobs. You can also connect to the client hosting Oracle Enterprise Manager and use the Oracle Enterprise Manager to access RMAN. The Pinnacle CNS configuration presents the RMAN on the same node of the database with separate backup.

About the RMAN Executable

RMAN is the client application that manages backup and recovery operations for a target database. The RMAN executable is automatically included with the Oracle software installation. The RMAN client uses Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net.

About the Target Database

The target database is made up of the control files, datafiles, and optional archived redo logs that RMAN is in charge of backing up, restoring, or recovering. RMAN uses the target database control file to gather information about the database and to store information about its own operations. The actual work of the backup and recovery jobs is performed by server sessions on the target database. You can use a recovery catalog to manage the metadata of the database.

Create Backup Configuration

Enterprise Manager creates a default backup configuration for each target database, but you can use the Create Backup Configuration property sheets to create other backup configurations for backup and recovery. A configuration can be used for one database or many databases depending if the systems are the same.

About the Recovery Catalog Database

A recovery catalog database is a database containing the recovery catalog schema, which contains the metadata that RMAN uses to perform its backup and recovery operations.

About the Recovery Catalog Schema

The Recovery Catalog Schema is the user within the recovery catalog database that owns the metadata tables maintained by RMAN. RMAN uses these metadata tables to store information about the target database and its backup and recovery operations. Among other things, RMAN stores information about:

• Backup sets and pieces
• Image copies
• Proxy copies
• Archived redo logs
• The target database schema
• Persistent configuration settings

You can either use a recovery catalog in which to store the repository, or let RMAN store the repository exclusively in the target database control file.

Although RMAN can conduct all major backup and recovery operations using just the control file, note these advantages of using the catalog:

• Some RMAN commands and operations function only with a catalog.
• The recovery catalog retains historical backup information that can get overwritten in the control file.
• The recovery catalog stores information about backups from different incarnations of the database.

The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN automatically 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.
For Oracle9i and later, a recovery catalog is created if you specify for the Enterprise Manager repository to be located in a local database. The recovery catalog will be created in the CATTBS tablespace for you by default with the recovery catalog user and password of rman/rman. Important

The recovery catalog and the Oracle Enterprise Manager repository should not reside in the target database (database to be backed up). The recovery catalog can reside in the same database as your Oracle Enterprise Manager repository. Oracle recommends placing the recovery catalog in a separate tablespace. As with any important data, you should back up your recovery catalog regularly.

About the Standby Database

A standby database is a copy of the primary database that is updated using archived logs created by the primary database. RMAN can create or back up a standby database.

About the RMAN Media Management Interface

To store backups on tape, RMAN requires a media manager, which is a vendor-specific application. A media manager is a software program that loads, labels, and unloads sequential media such as tape drives used to back up and recover data. For information on configuring RMAN to make backups to a media manager, refer to the Oracle9i Recovery Manager User's Guide.

When doing backups or restores, the RMAN client connects to the target instance and directs the instance to talk to its media manager. No direct communication occurs between the RMAN client and the media manager: all communication occurs on the target instance.

RMAN Backup

A backup is a copy of data. This copy can include important parts of the database such as the control file and datafiles. A backup is a safeguard against unexpected data loss and application errors. If you lose the original data, then you can reconstruct it by using a backup.

This section contains the following topics:

• Backing Up a Database
   • Backing Up a Database Using a Predefined Strategy
   • Backing Up the Database with a Customized Strategy
   • Deleting Obsolete Backups and Copies
   • Selecting a Full or Incremental Backup
   • Choosing an Online or Offline Mode to Back Up Your Database
• Backing Up Individual Files
• Backing Up and Deleting Archived Logs
• Copying a Datafile
• Overriding a Retention Policy in Backup for Special Cases

Backing Up a Database

Backing Up a Database Using a Predefined Strategy

Select Predefined backup strategy on the Strategy choice page of the Backup Wizard if you want to back up your entire database without having to make too many decisions. The Backup Frequency page appears with general descriptions from which you can choose.

Picking a Description that Fits Your Database. Pick the description that fit your database in the Backup Frequency page, and RMAN will decide how often to perform a backup based on the general description that you pick.

Specifying the Number of Backups to Retain. If the selected (target) database is Oracle 9i and later, the Retain at least the specified number of backups for each datafile and delete obsolete backups after every backup checkbox and the Number of backups field are enabled in the Backup Frequency page. The default value is 2 for the number of backups to retain in the Number of backups field. With this default selection, the retention policy of the target database will be set to redundancy 2. At least the 2 most recent full backups will be retained for each datafile. Older backups will be deleted after each new backup is successfully performed.

Later Steps in the Predefined Strategy. Later, in the process, wizard pages will appear in which you will have the option to perform the following tasks:

• Specify the start time for performing the backup.
• Select the default configuration or any of the user created configurations for the backup. A default configuration is created by Enterprise Manager for each target database.
• Specify multiple targets to submit the job. Note: To submit the same backup to multiple targets, the databases must have the same structure and the same disk/tape configuration.

Backing Up the Database with a Customized Strategy

Select Customize backup strategy on the Strategy choice page of the Backup Wizard if you want to select the information you want to back up and the schedule for the execution of the backup. If the target database is 9i or above and the retention policy has been set in the target database, you can also choose to delete obsolete backups after the backup. The retention policy determines which backups and image copies are obsolete. If selected, the obsolete backups and copies will be deleted when the backup is finished. Later in the process, wizard pages will appear in which you will have the option to perform the following tasks:

• Choose whether to include archive logs in the backup and if they should be deleted after each backup.
• Select a full or an incremental backup.
• Choose the online backup or offline backup mode.
• Select the default configuration or any of the user created configurations for the backup. A default configuration is created by Enterprise Manager for each target database.
• Choose to override the backup and retention policy.
• Schedule the execution of a backup.
• Select when to submit the job and whether to add it to the job library.
• Specify multiple targets to submit the job. Note: To submit the same backup to multiple targets, the databases must have the same structure and the same disk/tape configuration.

Deleting Obsolete Backups and Copies

If you are using a customized backup strategy and if the target database is 9i or above and the retention policy has been set in the target database, you can choose to have obsolete backups and copies deleted after the backup.

The retention policy determines which backups and image copies are obsolete. The current retention policy setting may be viewed through the Maintenance Wizard on the "Retention Policy" page. The retention policy may be modified through the Maintenance Wizard by submitting an Enterprise Manager job.

Select Delete obsolete backups after this backup on the Backup Selection page of the Backup Wizard. The retention policy determines which backups and image copies are obsolete. If selected, the obsolete backups and copies will be deleted when the backup is finished.

Selecting a Full or Incremental Backup

If you are using a customized strategy for your backup, you can choose to perform a full or an incremental level backup.

A full backup

A full backup backs up all blocks into the backup set, skipping only datafile blocks that have never been used. The server process does not skip blocks when backing up archived redo logs or control files. A full backup has no effect on subsequent incremental backups, which is why it is not considered part of the incremental strategy. In other words, a full backup does not affect which blocks are included in subsequent incremental backups.

An incremental backup

Incremental backups are a convenient way to conserve storage space because they back up only database blocks that have changed.The primary reasons for making an incremental backup are:

• To save tape when using a media manager or disk space when making disk backups
• To save network bandwidth when backing up over a network. When the aggregate tape bandwidth available for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os
• To be able to recover changes to objects created with the NOLOGGING option (direct load inserts do not log redo, although they do change data blocks and so are captured by incremental backups)
• To reduce backup sizes for NOARCHIVELOG databases. Instead of making a whole database backup every time, you can make incremental backups. Note that incremental backups of a NOARCHIVELOG database are only legal after a consistent shutdown.
• Incremental backups are a method by which you only backup modified blocks. An incremental level 0 backup performs the same function as a full backup in that they both backup all blocks that have ever been used except a level 0 will affect what blocks are copied out by subsequent incremental backups.
Incremental backups of levels greater than 0 back up only blocks that have changed since previous incremental backups. Blocks which have not changed will not be backed up. When you choose to make an incremental backup, you can choose a non-cumulative or a cumulative backup.
A non-cumulative backup is a type of incremental backup in which you back up all blocks that have changed since the most recent backup at level n or lower. For example, in a differential level 2 backup you back up all blocks modified since the last level 2, level 1, or level 0 backup. A non-cumulative backup copies less data and therefore takes a shorter time than the cumulative backup, but recovery time may be longer based on the number of incremental backups that must be applied.

A cumulative backup is a type of incremental backup that allows you to back up all the blocks used since the most recent backup at level n-1 or lower. For example, in a cumulative level 2 backup you back up all blocks used since the most recent level 1 or level 0 backup. A cumulative backup copies more data and therefore takes longer than the non-cumulative backup, but recovery time is shorter.

Incremental Backup Strategy

Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 backup is taken weekly, and a cumulative level 2 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.

When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate.

Choosing an Online or Offline Mode to Back Up Your Database

If you are making a database backup using a customized strategy and the target database is in ARCHIVELOG mode, you can choose to make an online or an offline backup.

Online Backup

An online backup is a backup of one or more datafiles taken while a database is open and the datafiles are online. Online Backup is the default selection. If the database is in the OPEN state, the database backup will be performed while the database is OPEN.

Offline Backup

An offline backup is a backup when the database is not open. If you choose Offline Backup, the database will be backed up in the MOUNT state. If the database is in the OPEN state, it will be shut down and brought to the MOUNT state before the backup is performed. When the backup is finished, the database will be brought back to OPEN state.

Backing Up Individual Files

Your database contains a wide variety of types of data. When developing your backup strategy, you must decide what information you want to back up. The basic principle you should use when deciding what to back up is to prioritize data depending on its importance and the degree to which it changes.

If the target database is 9i or above and the retention policy has been set in the target database, you can also choose to delete obsolete backups after the backup.

Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs by issuing selecting Archive Logs from a customized backup strategy or by backing up datafiles and control files and specifying to include archive logs in the backup.

Typically, database administrators back up archived logs on disk to a third-party storage medium such as tape. You can also back up archived logs to disk.

Backing Up Archived Logs

The default value for number of backups is 2. You may modify the value. With this selection, only archived logs with enough number of backups will be deleted after this backup. Deleting archive logs saves space. Each archived log will be backed up once before it is deleted.

Copying a Datafile

An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. RMAN only writes image copies to disk.

Check the Use an image copy box if you want to back up a datafile using an image copy. Oracle supports performing a backup using an image copy of datafiles, or controlfiles. You can only perform an image copy of a controlfile with an image copy of a datafile. Using an image copy of only the controlfile is directly supported from the Backup Wizard. You may submit a "Run Rman Script" job separately from the Console to perform the controlfile image copy.

Overriding a Retention Policy in Backup for Special Cases

Backup and retention policies are a set of parameters set in the database which define how to perform a backup and how backups are retained. Once configured, these parameters apply to all the subsequent backups, but you can choose to override these backup and retention polices.

Overriding the Backup Policy

The Do not optimize this backup option is enabled when the database has been configured to use backup optimization (from the Maintenance Wizard) and you have chosen to perform a database or archivelog backup. If checked, the Backup Wizard generates the "force" option in the RMAN command. The files are backed up even if they have not changed since the last backup. Choose this option if you want to override the backup optimization configuration.

The Include all the tablespaces in the complete database backup option is available if the target database has been configured to exclude some tablespaces from a database backup and you are planning to make a database backup. This allows you to override the "exclude for tablespace" configuration and include all tablespaces in the database backup. This corresponds to the "noexclude" option in RMAN.

Overriding the Retention Policy

The Keep this backup or copy until option allows you to override the retention policy and keep the backup or copy until a specified time is available if a retention policy has been set in the target database. If the database is in ARCHIVELOG mode and you are planning to perform an online backup, the necessary archived logs will be kept to allow recovery of the database.

If the database is in ARCHIVELOG mode and you are planning to perform an offline backup, you have the option of whether to keep the subsequent archived logs or their backups.

Refer to the choices below:

• Keep the backups of the subsequent logs for a point-in-time recovery.If the subsequent logs are kept, a point-in-time recovery to any time between the backup time and today.
• Do not use the backup for a point-in-time recovery. The subsequent logs may be deleted when they become obsolete.

If the logs are not kept, the backup can only be used for vaulting purpose and and can be used only for recovery to the point of time when backup was taken.

Recovery

Instance and crash recovery are the automatic application of redo log records to Oracle data blocks after a crash or system failure. During normal operation, if an instance is shutdown cleanly as when using a SHUTDOWN IMMEDIATE statement, rather than terminated abnormally, then the in-memory changes that have not already been written to the datafiles on disk are written to disk as part of the checkpoint performed during shutdown.

However, if a single instance database crashes or if all instances of an Oracle Real Application Cluster configuration crash, then Oracle performs crash recovery at the next startup. If one or more instances of an Oracle Real Application Cluster configuration crash, then a surviving instance performs instance recovery automatically. Instance and crash recovery occur in two steps: cache recovery followed by transaction recovery.

Cache Recovery (Rolling Forward)

During the cache recovery step, Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. The work required for cache recovery processing is proportional to the rate of change to the database (update transactions each second) and the time between checkpoints.

Transaction Recovery (Rolling Back)

To make the database consistent, the changes that were not committed at the time of the crash must be undone (in other words, rolled back). During the transaction recovery step, Oracle applies the rollback segments to undo the uncommitted changes. The work required to do transaction recovery is proportional to the number and size of uncommitted transactions when the system fault occurred.

Restore and Recover

Typically, you restore and recover a database or subset of a database in the following cases:

• A media failure has damaged some or all control files or datafiles.
• You want to recover the database to a point before a user error, such as a dropped table, occurred.

The basic procedure for performing restore and recovery with RMAN is as follows:

1. Determine which database files require recovery.
2. From the Backup Management menu, choose Recover to access the Recovery Wizard to recover the restored files.
3. On the Operation Selection page, select your choice. The choices which appear on this page depends on your database's state. The default operation is to perform a restore and recover. Restore only, recover only, and recover data blocks only are advanced options. You may choose to perform a restore only in one of the following situations:

• if DBVERIFY will be run against the restored files before a recovery.
• if only archived logs need to be restored.
• if datafiles or tablespaces need to be restored from an older backup set.

You may choose to perform a recovery only if you have restored the files before or you know there is no need to restore files. You may choose to recover data blocks only in a 9i database if you know the corruption is limited to a few data blocks.

1. If the Operation Selection page does not display the choice you want, place the database in the state appropriate for the type of recovery that you want to perform.
2. In the Object Selection page, select a restore and/or recovery operation for the Entire Database, Tablespaces, Datafiles, or Archivelogs. Depending on the status of the target database, some options will be disabled or do not appear.

Recovering the Entire Database

A recovery of an entire database is a recovery of all database files that belong to a database. RMAN uses the backups and copies that you made earlier and restores the files to their correct locations. Then, it uses archived redo logs (if needed) to recover the database. You can recover the entire database to the latest time or to a point in time if the database is in ARCHIVELOG mode and MOUNT state.

You can select to recover the database to a point-in-time in the past if you have selected Restore and recover or Recover only on the Operation Selection page, and the database is in the MOUNT state and ARCHIVELOG mode.

Restoring the Entire Database

You can specify a point-in-time in the past by giving a time, an SCN or a log sequence number if you had selected Restore only in the Operation Selection page. If the database is in NOARCHIVELOG mode and MOUNT state, you can restore only the entire database. When you run your database in NOARCHIVELOG mode, the filled online redo log files are not archived. If the database's redo log operates in NOARCHIVELOG mode, the database can be completely recovered from instance failure but not from disk failure. Also, the database can be backed up only while it is completely closed. Because no archived redo log is created, no extra work is required by the database administrator.

Recovering and/or Restoring Tablespaces or Datafiles

It is not uncommon for a media failure to affect some but not all files in a database. You can recover tablespaces or datafiles to the latest time if

• the database is in ARCHIVELOG mode and MOUNT state
• the database is in ARCHIVELOG mode and OPEN state

Specify if you want to restore the files to a different location and rename them. Select the default configuration or any of the user created configurations for the backup. A default configuration is created by Enterprise Manager for each target database.

Restoring the Control File

When the database is in the NOMOUNT (Started) state and there are no backup configurations which use a recovery catalog, you can restore a controlfile from a controlfile autobackup for Oracle 9.0.1 target databases.

If you have performed backups to tape, your controlfile autobackups are located on both disk and tape. To restore the controlfile from autobackup, select the backup configuration you used when backing up to tape. Both tape and disk will be searched and the latest autobackup will be used to restore the controlfile.

If you have never performed a backup to tape, all your controlfile autobackups are located on disk. To restore the controlfile from autobackup, select the backup configuration you used to backup to disk. The latest autobackup will be used to restore the controlfile.

RMAN requires the DBID to be specified when restoring controlfile from autobackup. If you have performed at least one backup from the Enterprise Manager Backup Wizard, the DBID is stored in the Enterprise Manager repository and the value is filled in the DBID field. Otherwise you will have to enter the DBID manually.

If you have specified a location for the autobackup on disk using the Maintenance Wizard, the location is stored in the Enterprise Manager repository and the value is filled in the location field. Otherwise you have to fill in the value manually. If you do not specify a value, the default location will be searched for autobackups on disk.

Restoring Archive Log Files

You can restore archive log files for use with LogMiner Viewer if they are no longer on disk.

To restore archived logs, a range has to be specified using one of the three methods:

1. Specify archived log range by time.
2. Specify archived log range by SCN.
3. Specify archived log range by log sequence.

Recovering Datablocks

You can recover datablocks if

• the database is in ARCHIVELOG mode and MOUNT state, or
• the database is in ARCHIVELOG mode and OPEN state

Using a Corruption List for Data Block Recovery

The Corruption List option is the default and preferred selection for most users. All the data blocks that have been identified corrupted by RMAN during the backup and copy operations can be recovered.

Data block corruption in non-RMAN operations, such as dbverify, is not included in the corruption list. To recover those database blocks, you will have to find the block numbers or data block addresses of the corrupted blocks from Oracle standard output, an alert.log. user trace files, results of the ANALYZE TABLE and ANALYZE INDEX SQL commands, result of the DBVERIFY utility, or third-party media management output. However, the corrupted blocks are always recorded in the alter.log file.

The View Corruption List button is visible for 9.2 databases only. By clicking the button, a Corruption List dialog will appear, showing the current data blocks that are labeled corrupted by RMAN.

Using Datafiles for Data Block Recovery

Select the Datafiles option on the Block Media Recovery Method page if the block numbers of the corrupted data blocks can be found in one of the places listed above.

When the Data Block Selection by Datafile page appears, enter the block numbers of the corrupted data blocks for each datafile.

Using Tablespaces for Data Block Recovery

Select the Tablespaces option on the Block Media Recovery Method page if the data block addresses of the corrupted data blocks can be found in one of the places listed above.

Maintenance Operations

You will use the Maintenance wizard to help you perform maintenance operations on the target databases and on the recovery catalog.

Setting up Backup and Retention Ploicies in a Target Database

To set up backup and retention policies in a target database. From the Backup Management menu, choose Maintenance to access the Maintenance Wizard. On the Operation Choice page, select Modify backup and retention policies in the target database. You may modify persistent RMAN configurations in the target database using this option. The wizard proceeds to the Backup Policy and Retention Policy pages where you can modify backup related RMAN configuration parameters. This option is enabled for 9i and above databases only. A one time job will be submitted to execute the changes.

Configuring a Backup Policy

Choosing to automatically back up controlfile and server parameter file

By default this option is not selected, but it is highly recommended that you choose the option for your database and set the location for the autobackup on disk.

The controlfile and server parameter file (SPFILE) will be backed up automatically after each backup. Additionally these files are backed up automatically after each structural change in the database. The backups of these files are called controlfile autobackups.

If you are making a backup to disk, the controlfile and SPFILE will be automatically backed up to disk. The database backup location is determined by the format of the allocated disk channel. The controlfile autobackup is located in what is specified in the Location for the autobackup on disk field.

If you are making a backup to tape, the controlfile and SPFILE will be automatically backed to tape. The database backup format is determined by the format of the allocated tape channel. The controlfile autobackup format is always %F.

After each structural change (such as adding a tablespace or a datafile) in the database, the controlfile and SPFILE will always to backed up to disk.

The autobackup is located in what is specified in the Location for the autobackup on disk field below.

Specify the Location for the autobackup on disk. It is the location of the autobackups if you are making a backup to disk and after a database structural change. If you do not specify a location on disk, the default location will be used. The default location is on the same disk as the database. The default location is unlikely to be available when you need to restore the controlfile from autobackup. Therefore, it is highly recommended that you specify a disk location which is different from the database location.

If the autobackup format for disk has not been configured in the database, the location appears as %F. You are recommended to change the Directory path.

If the autobackup format for disk has been configured, the configured format will appear in the location field.

Choosing to optimize the backup

Database backup and archivelog backup may be optimized by skipping files that have not changed since the last backup. Typical examples of unchanged files include offline or read-only datafiles as well as archivelogs. Once backup optimization is set, archivelogs can only be backed up once unless you specify Yes, delete archived logs only after a specified number of backups option in the Backup Wizard's Archived Log Deletion page (available for 9.2 target databases).

Excluding tablespaces in a backup

You can choose to exclude some tablespaces from a complete database backup. These tablespaces can still be backed up separately using a tablespace backup. This option allows you to exclude some extremely large but rarely modified tablespaces from a database backup, and back them up on a different schedule. This may reduce the amount of time required for a regularly scheduled database backup.

Configuring a Retention Policy

A retention policy allows you to define how long to retain your backups before they are marked obsolete. Based on this policy, RMAN will mark backups you do not need as obsolete. You can delete obsolete backups by regularly running delete obsolete operations.

Select the Set the retention policy of backups option to use a retention policy. You can set the policy to retain backups so that you are able to recover database until the past "number of days"or to retain a "number of backup copies."

The Number of days option corresponds to "configure retention policy to recovery window of x days", where x is the value from the Number of days field.

The Number of backups option corresponds to "configure retention policy to redundancy y", where y is the value of the Number of backups field.

Select the No retention policy is set option if you want to manually delete backups. This option corresponds to RMAN's "configure retention policy to none" option.

Performing Recovery Catalog Maintenance

To register, reset, or resynchronize the target database with the recovery catalog

Registering a Database: The target database must be registered with the Recovery Catalog before the Backup wizard can use it. You only need to register the database once.

Resynchronizing the Catalog

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. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments, and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.

RMAN automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a RESYNC CATALOG command.

To ensure that the catalog stays current, run the RESYNC CATALOG command periodically if you run backups periodically.

You will not need to run the RESYNC CATALOG command if you perform at least one backup in n days, where n is the setting for the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. When you start the RMAN backup (or any other operation) it will automatically perform a "RESYNC CATALOG". In other words, if you perform a backup fairly often (for example, every 2-5 days), then there is no need to do "RESYNC CATALOG" manually.

Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.

Resetting the Database

Resetting the database is rarely performed and should only be done if all the information has been lost. You must reset the recovery catalog if the target database had been previously opened with the RESETLOGS option. Refer to the Oracle9i Recovery Manager User's Guide for information on the RESETLOGS option.

Copyright © 2004-2007 Open Systems Group, Computing and Networking Services, University of Florida.