What is an orphan incarnation?

Incarnations are explained in an answer to another question on this site. The answer mentions 'orphaned' incarnations:


…There are other factors that result in ORPHANED incarnations and OBSOLETE backups…

I see from the Oracle docs that V$DATABASE_INCARNATION includes a STATUS column which can have values of ORPHAN, CURRENT or PARENT, which must be related.

What are 'orphaned' incarnations, and what steps would result in a row with STATUS=ORPHAN in V$DATABASE_INCARNATION?

Following is a short graphic which I will be using to explain when orphans are created in the incarnations of a database. It is a variation of the graphic I used to explain incarnations in my answer to the question Can anyone explain to me the concept “incarnation” in Oracle database in an easy-to-understand way?

I hope you enjoy the journey.

restore db +-----+ +-----+ +-----+
recover db | 2>3 | --> | 3 | --> | 3 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn 3 3 | 3
/ SCN # 500 600 | 700
/ |
/ |
restore db +-----+ +-----+ +-----+ |
recover db | 1>2 | -------> | 2 | --> | 2 | --> ... |
resetlogs +-----+ +-----+ +-----+ ^ |
^ Incarn. 2 \ 2 | 2 |
/ SCN # 300 \ 400 | 500 |
/ \ | |
/ + --------------------+ |
+-----+ +-----+ +-----+ | \ +-----+ | +-----+
--> | 1 | --> | 1 | --> | 1 | --> ... | +-> | 2>4 | --> | 4 |
+-----+ +-----+ +-----+ ^ | restore db +-----+ | +-----+
Incarn. 1 1 1 | 1 2 | recover db | 4
SCN # 100 200 300 | 400 400 | resetlogs | 400
| | |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00 ----- 18:00
| | |
Restore/ (1) (2) (3)
Recovery


Restoring the Database to Point in Time (1)

Somewhere slightly after 13:00 (1pm) somebody decides that the database has to be restored to 12:00 (12 o'clock midday). The DBA either sets off a bunch of RMAN commands to restore the database to that point in time or clicks his way through a fantastic GUI to initiate a restore/recovery from a 3rd-party vendor.

RMAN retrieves the FULL backup of the database and all Archive Log backups from disk/tape and restores them to the disk. In the recovery phase RMAN will check that all relevant information is available and roll forward all finished transactions to the Point in Time and roll back all unfinished transactions to the Point in Time, to ensure the database is in a consistent state.

Before the database can be opened to the general public, the database has to ensure that all future backups don't conflict with the previous backups. This is when a new incarnation should be created and it happens when you execute the following command to open the database:

ALTER DATABASE OPEN RESETLOGS;

You can run the following script against your instance to retrieve a hierarchical view of your (current) incarnations:

set pages 50               --- repeat header every 50 records
set lines 230              --- set lines(ize) length to 230
column path format a40     --- set column path to alpha-numeric 40
alter sessiosn set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
                           --- set date format of date columns to something more detailed
select 
    INCARNATION#, 
    PRIOR_INCARNATION#, 
    RESETLOGS_CHANGE#, 
    RESETLOGS_TIME, 
    STATUS, 
    SYS_CONNECT_BY_PATH(INCARNATION#, ' -> ') Path 
    FROM v$database_incarnation 
    WHERE LEVEL >=1 START WITH INCARNATION# = '1' 
        CONNECT BY PRIOR INCARNATION# = PRIOR_INCARNATION# 
    ORDER BY LEVEL, Path, RESETLOGS_TIME;

The current incarnation of the database will be similar to this:

`INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1

StackExchange Database Administrators Q#213317, answer score: 8