13 RMAN Data Repair Concepts

Problems Requiring Data Repair

While several problems can halt the normal operation of an Oracle database or affect database I/O operations, only the following typically require DBA intervention and data repair: user errors, application errors, and media failures.

RMAN Data Repair Techniques

Depending on the situations you anticipate, consider incorporating each of the following options into your strategy for responding to data loss, and then set up your database to make these options possible.

• Data Recovery Advisor

  This Oracle Database infrastructure can diagnose failures, advise you on how to respond to them, and repair the failures automatically.

  "Overview of Data Recovery Advisor" explains the basic concepts of Data Recovery Advisor.

• logical flashback features

  This subset of Oracle Flashback Technology features enables you to view or rewind individual database objects or transactions to a past time. These features do not require use of RMAN.

  "Overview of Flashback Technology and Database Point-in-Time Recovery" explains the basic concepts of the logical flashback features and provides pointers where appropriate.

• Oracle Flashback Database

  Flashback Database is a block-level recovery mechanism that is similar to media recovery, but is generally faster and does not require a backup to be restored. You can return your whole database to a previous state without restoring old copies of your datafiles from backup, as long as you have enabled flashback logging in advance. You must have a fast recovery area configured for logging for flashback database or guaranteed restore points.

  "Basic Concepts of Point-in-Time Recovery and Flashback Features" explains the basic concepts of Flashback Database.

• datafile media recovery

  This form of media recovery enables you to restore datafile backups and apply archived redo logs or incremental backups to recover lost changes. You can either recover a whole database or a subset of the database. Datafile media recovery is the most general-purpose form of recovery and can protect against both physical and logical failures.

  The general concepts of datafile media recovery are explained in this chapter. The techniques are described in Chapter 16, "Performing Complete Database Recovery" and "Performing Database Point-in-Time Recovery".

• block media recovery

  This form of media recovery enables you to recover individual blocks within a datafile rather than the whole datafile.

  "Overview of Block Media Recovery" explains the basic concepts of block media recovery.

• tablespace point-in-time recovery (TSPITR)

  This is a specialized form of point-in-time recovery in which you recover one or more tablespaces to a time earlier than the rest of the database.

  "Overview of RMAN TSPITR" explains the basic concepts of TSPITR.

In general, the concepts required to use the preceding repair techniques are explained along with the techniques. This chapter explains concepts that are common to several RMAN data repair solutions.

Backup Selection

RMAN uses the records of available backup sets or image copies in the RMAN repository to select the best available backups for use in the restore operation. The most recent backup available, or the most recent backup satisfying any UNTIL clause specified in the RESTORE command, is the preferred choice. If two backups are from the same point in time, then RMAN prefers image copies over backup sets because RMAN can restore more quickly from image copies than from backup sets (especially those stored on tape).

All specifications of the RESTORE command must be satisfied before RMAN restores a backup. Unless limited by the DEVICE TYPE clause, the RESTORE command searches for backups on all device types of configured channels. If no available backup in the repository satisfies all the specified criteria, then RMAN returns an error indicating that the file cannot be restored.

If you use only manually allocated channels, then a backup job may fail if there is no usable backup on the media for which you allocated channels. Configuring automatic channels makes it more likely that RMAN can find and restore a backup that satisfies the specified criteria.

If backup sets are protected with backup encryption, then RMAN automatically decrypts them when their contents are restored. Transparently encrypted backups require no intervention to restore, as long as the Oracle wallet is open and available. Password-encrypted backups require the correct password to be entered before they can be restored.

Restore Failover

RMAN automatically uses restore failover to skip corrupted or inaccessible backups and look for usable backups. When a backup is not found, or contains corrupt data, RMAN automatically looks for another backup from which to restore the desired files.

RMAN generates messages that indicate the type of failover that it is performing. For example, when RMAN fails over to another backup of the same file, it generates a message similar to the following:

failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009

If no usable copies are available, then RMAN searches for previous backups. The message generated is similar to the following example:

ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup

RMAN will perform restore failover repeatedly until it has exhausted all possible backups. If all of the backups are unusable or no backups exists, then RMAN attempts to re-create the datafile. Restore failover is also used when there are errors restoring archived redo logs during RECOVER, RECOVER ... BLOCK, and FLASHBACK DATABASE commands.

Restore Optimization

RMAN uses restore optimization to avoid restoring datafiles from backup when possible. If a datafile is already present in the correct location and its header contains the expected information, then RMAN does not restore the datafile from backup.

You can use the FORCE option of the RESTORE command to override this behavior and restore the requested files unconditionally.

Restore optimization is particularly useful when an operation that restores several datafiles is interrupted. For example, assume that a full database restore encounters a power failure after all except one of the datafiles has been restored. If you run the same RESTORE command again, then RMAN only restores the single datafile that was not restored during the previous attempt.

Restore optimization is also used when duplicating a database. If a datafile at the duplicate is in the correct place with the correct header contents, then the datafile is not duplicated. Unlike RESTORE, DUPLICATE does not support a FORCE option. To force RMAN to duplicate a datafile that is skipped due to restore optimization, delete the datafile from the duplicate before running the DUPLICATE command.

Selection of Incremental Backups and Archived Redo Logs

RMAN automates media recovery. RMAN automatically restores and applies both incremental backups and archived redo logs in whatever combination is most efficient.

If the RMAN repository indicates that no copies of a required log sequence number exist on disk, then will automatically restore the required log from backup. By default, RMAN restores the archived logs to the fast recovery area, if one of the archiving destinations is set to USE_DB_RECOVERY_FILE_DEST. Otherwise, RMAN restores the logs to the first local archiving destination specified in the initialization parameter file.

Database Incarnations

A database incarnation is created whenever you open the database with the RESETLOGS option. After complete recovery, you can resume normal operations without an OPEN RESETLOGS. After a DBPITR or recovery with a backup control file, however, you must open the database with the RESETLOGS option, thereby creating a new incarnation of the database. The database requires a new incarnation to avoid confusion when two different redo streams have the same SCNs, but occurred at different times. If you apply the wrong redo to your database, then you will corrupt it.

The existence of multiple incarnations of a single database determines how RMAN treats backups that are not in the current incarnation path. In almost all cases, the current database incarnation is the correct one to use. Nevertheless, in some cases resetting the database to a previous incarnation is the best approach. For example, you may be dissatisfied with the results of a point-in-time recovery that you have already performed and want to return the database to a time before the RESETLOGS. An understanding of database incarnations is helpful to prepare for such situations.

Relationship Among Database Incarnations

Database incarnations can stand in the following relationships to each other:

• The current incarnation is the one in which the database is currently operating.

• The incarnation from which the current incarnation branched following an OPEN RESETLOGS operation is the parent incarnation of the current incarnation.

• The parent of the parent incarnation is an ancestor incarnation. Any parent of an ancestor incarnation is also an ancestor of the current incarnation.

• The direct ancestral path of the current incarnation begins with the earliest incarnation and includes only the branches to an ancestor of the current incarnation, the parent incarnation, or the current incarnation.

An incarnation number is used to uniquely tag and identify a stream of redo. Figure 13-1 illustrates a database that goes through several incarnations, each with a different incarnation number.

Figure 13-1 Database Incarnation History

Description of "Figure 13-1 Database Incarnation History"

Incarnation 1 of the database starts at SCN 1 and continues through SCN 1000 to SCN 2000. Suppose that at SCN 2000 in incarnation 1, you perform a point-in-time recovery back to SCN 1000, and then open the database with the RESETLOGS option. Incarnation 2 now begins at SCN 1000 and continues to SCN 3000. In this example, incarnation 1 is the parent of incarnation 2.

Suppose that at SCN 3000 in incarnation 2, you perform a point-in-time recovery to SCN 2000 and open the database with the RESETLOGS option. In this case, incarnation 2 is the parent of incarnation 3. Incarnation 1 is an ancestor of incarnation 3.

When DBPITR or Flashback Database has occurred in database, an SCN can refer to more than one point in time, depending on which incarnation is current. For example, SCN 1500 in Figure 13-1 could refer to an SCN in incarnation 1 or 2.

You can use the RESET DATABASE TO INCARNATION command to specify that SCNs are to be interpreted in the frame of reference of a specific database incarnation. The RESET DATABASE TO INCARNATION command is required when you use FLASHBACK, RESTORE, or RECOVER to return to an SCN in a noncurrent database incarnation. However, RMAN executes the RESET DATABASE TO INCARNATION command implicitly with Flashback, as explained in "Resetting the Database Incarnation in the Recovery Catalog".

See Also:

• "Recovering the Database to an Ancestor Incarnation"

• Oracle Database Backup and Recovery Reference for details about the RESET DATABASE command