14.3.2 About 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 corrupt it.
The existence of multiple incarnations of a single database determines how RMAN treats backups that are not in the current incarnation path. Usually, 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 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.
14.3.2.1 About RMAN OPEN RESETLOGS Operations
RMAN performs certain actions when you open the database with the RESETLOGS option.
The action performed are as follows:
-
Archives the current online redo logs (if they are accessible) and then erases the contents of the online redo logs and resets the log sequence number to 1.
For example, if the current online redo logs are sequence 1000 and 1001 when you open
RESETLOGS, then the database archives logs 1000 and 1001 and then resets the online redo logs to sequence 1 and 2. -
Creates the online redo log files if they do not currently exist.
-
Initializes redo thread records and online redo log records in the control file to the beginning of the new database incarnation.
More specifically, the database sets the redo thread status to closed, sets the current thread sequence in the redo thread records to 1, sets the thread checkpoint of each redo thread to the beginning of log sequence 1, chooses one redo log from each thread and initialize its sequence to 1, and so on.
-
Updates all current data files and online redo logs and all subsequent archived redo logs with a new
RESETLOGS SCNand time stamp.
Because the database does not apply an archived redo log to a data file unless the RESETLOGS SCN and time stamps match, the RESETLOGS requirement prevents you from corrupting data files with archived logs that are not from direct parent incarnations of the current incarnation. The relationship among incarnations is explained more fully in the following section.
In previous releases, it was recommended that you back up the database immediately after the OPEN RESETLOGS. Because you can now easily recover a pre-RESETLOGS backup like any other backup, making a new database backup is optional. To perform recovery through RESETLOGS you must have all archived logs generated after the most recent backup and at least one control file (current, backup, or created).
14.3.2.2 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 RESETLOGSoperation 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 14-1 illustrates a database that goes through several incarnations, each with a different incarnation number.
Figure 14-1 Database Incarnation History
Description of "Figure 14-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 multiple points in time, depending on which incarnation is current. For example, SCN 1500 in Figure 14-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".
END