Database Incarnations

INCARNATION可以翻译为转世

在使用数据库的时间点恢复或使用备份控制文件恢复后必须使用OPEN RESETLOGS

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.

• RMAN OPEN RESETLOGS Operations

RMAN performs certain actions when you open the database with the RESETLOGS option.

The action performed are as follows:

1. 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.
2. Creates the online redo log files if they do not currently exist.
3. Initializes redo thread records and online redo log records in the control file to the beginning of the new database incarnation.
4. Updates all current data files and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp.

RESETLOGS SCN保证了数据文件不会应用不匹配的归档日志

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.

没必要在OPEN RESETLOGS后进行全备

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.

• Relationship Among Database Incarnations

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

1. The current incarnation is the one in which the database is currently operating.
2. The incarnation from which the current incarnation branched following an OPEN RESETLOGS operation is the parent incarnation of the current incarnation.
3. The parent of the parent incarnation is an ancestor incarnation. Any parent of an ancestor incarnation is also an ancestor of the current incarnation.
4. 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.

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.

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

Incarnation的相关命令

1. 查看incarnation

RMAN> list incarnation;

V$database_incarnation包含所有incarnations, v$database只包含当前及上个incarnation

V$DATABASE_INCARNATION displays information about all database incarnations. Records about the current and immediately previous incarnation are also contained in the V$DATABASE view.

SQL> select INCARNATION#, RESETLOGS_TIME,STATUS, PRIOR_INCARNATION#, FLASHBACK_DATABASE_ALLOWED from V$DATABASE_INCARNATION;

1. 切换incarnation:

RMAN> reset database to incarnation 11;    --数据库mount状态

• Incarnations of PDBs

A pluggable database (PDB) incarnation is a subincarnation of the multitenant container database (CDB) and is expressed as (database_incarnation, pdb_incarnation).

For example, if the CDB is incarnation 5, and a PDB is incarnation 3, then the fully specified incarnation number of the PDB is (5, 3). The initial incarnation of a PDB is 0. Subsequent incarnations are unique but not always sequential numbers.

The V$PDB_INCARNATION view contains information about all PDB incarnations. Use the following query to display the current incarnation of a PDB:

SELECT PDB_INCARNATION# FROM V$PDB_INCARNATION

   WHERE STATUS = 'CURRENT' AND CON_ID = PDB_container_id;

• Orphaned Backups

不在direct ancestral path的备份称为孤立备份Orphaned backup. 未在direct ancestral path的incarnations称为abandoned incarnations或orphaned incarnations

When a database goes through multiple incarnations, some backups can become orphaned backups. Orphaned backups are backups created during incarnations of the database that are not in the direct ancestral path.

Assume the scenario shown in Figure 14-1. If incarnation 3 is the current incarnation, then the following backups are orphaned:

All backups from incarnation 1 after SCN 1000

All backups from incarnation 2 after SCN 2000

In contrast, the following backups are not orphaned because they are in the direct ancestral path:

All backups from incarnation 1 before SCN 1000

All backups from incarnation 2 before SCN 2000

All backups from incarnation 3

RMAN可以直接使用direct ancestral path中备份恢复到任意子incarnation

You can use orphaned backups when you intend to restore the database to an SCN not in the direct ancestral path. RMAN can restore backups from parent and ancestor incarnations and recover to the current time, even across OPEN RESETLOGS operations, if a continuous path of archived logs exists from the earliest backups to the point to which you want to recover.

如果还原了direct ancestral path的控制文件就可以使用orphaned backups

If you restore a control file from an incarnation in which the changes represented in the backups had not been abandoned, then RMAN can also restore and recover orphaned backups.

• Orphaned PDB Backups

Orphan PDB backups can result when you perform point-in-time recovery on a pluggable database (PDB) and then open the PDB using the RESETLOGS option.

Orphan PDB backups are backups that were created when the SCN or time value was between the SCN or time to which the PDB was recovered and the SCN or time at which the PDB was opened in RESETLOGS mode.

The END_RESETLOGS_SCN column of the V$PDB_INCARNATION view contains the SCN at which the PDB is opened in RESETLOGS mode.

• Flashback and Database Point-in-Time Recovery Scenarios

闪回数据库与数据库的时间点恢复均可以回到任意incarnations，详见各文档说明

1. 闪回数据库可回到direct ancestral path中，不需要执行RESET DATABASE TO INCARNATION
2. 闪回数据库如果想回到abandoned incarnations才执行RESET DATABASE TO INCARNATION
3. 数据库时间点恢复到非当前incarnations均要执行RESET DATABASE TO INCARNATION
4. 数据库时间点恢复还需要还原相应incarnation的控制文件

如下图所示，如果想从incarnation 3 scn 3000回到incarnation 1 scn 500时，闪回直接flashback database to scn 500即可，而DBPITR则要执行reset database to incarnation 1

如果想从incarnation 3 scn 3000回到incarnation 1 scn 1500时，闪回与数据库均需要先执行reset database to incarnation 1然后执行flashback database to scn 1500或run{set until scn 1500; restore controlfile; alter database mount; restore database; recover database; }