在本网站上对另一个问题的回答中，对麻省进行了解释。答案提到“孤儿”的化身：
…还有其他因素导致ORPHANED化身和过时的备份…
我看到从Oracle的文档其V$DATABASE_INCARNATION包括STATUS列，其可以具有的值ORPHAN，CURRENT或者PARENT，必须是相关的。
什么是“孤立的”化身，以及哪些步骤将导致带有STATUS= ORPHANin 的行V$DATABASE_INCARNATION？
在本网站上对另一个问题的回答中，对麻省进行了解释。答案提到“孤儿”的化身：
…还有其他因素导致ORPHANED化身和过时的备份…
我看到从Oracle的文档其V$DATABASE_INCARNATION包括STATUS列，其可以具有的值ORPHAN，CURRENT或者PARENT，必须是相关的。
什么是“孤立的”化身，以及哪些步骤将导致带有STATUS= ORPHANin 的行V$DATABASE_INCARNATION？
Answers:
以下是一个简短的图形，我将用它来解释何时在数据库的化身中创建孤儿。这是我在回答问题时用来解释化身的图形的一种变体，谁能以一种易于理解的方式向我解释Oracle数据库中“化身”的概念吗？
希望您旅途愉快。
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
13:00（下午1点）之后不久的某个地方，有人决定必须将数据库还原到12:00（正午12点）。DBA要么启动一堆RMAN命令以将数据库还原到该时间点，要么通过出色的GUI单击自己的方式来启动第三方供应商的还原/恢复。
RMAN从磁盘/磁带检索数据库的FULL备份和所有存档日志备份，并将它们还原到磁盘。在恢复阶段，RMAN将检查所有相关信息是否可用，并将所有已完成的事务前滚到时间点，并将所有未完成的事务前滚到时间点，以确保数据库处于一致状态。
在向公众开放数据库之前，数据库必须确保所有将来的备份都不会与以前的备份冲突。这是当应该创建新的化身的时候，并且当您执行以下命令来打开数据库时会发生这种情况：
ALTER DATABASE OPEN RESETLOGS;您可以对实例运行以下脚本以检索（当前）化身的层次结构视图：
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;
数据库的当前版本将与此类似：
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 CURRENT -> 1 -> 2
使用该图形，我们可以看到我们已经从包含化身1的路径移动到具有化身2的路径，因为我们打开了数据库，RESETLOGS数据库创建了一个新的化身。
再次让我们假设数据库在执行第一次还原/恢复操作之后并在15:00（下午3点）之后稍微保持运行，有人决定需要在同一天的15:00（下午3点）将新的还原/恢复恢复到全时。
RMAN将还原文件，恢复数据库并启动ALTER DATABASE OPEN RESETLOGS使数据库恢复在线状态。现在将INCARNATION＃设置为3，并且在16:00的第一个备份将包含以下信息：
INCARNATION# 3
SCN# 500
Time......... 16:00
如果使用上面的脚本查询数据库中的化身，我们将得到如下信息：
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-27 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-27 15:20:00 CURRENT -> 1 -> 2 -> 3
让我们再次假设数据库在第二次还原/恢复操作之后继续运行，并且在17:00（下午5点）之后不久，有人决定需要在同一天回到14:00（下午2点）进行新的还原/恢复。
RMAN将还原文件，恢复数据库并启动ALTER DATABASE OPEN RESETLOGS使数据库恢复联机。现在将INCARNATION＃设置为4，并且在18:00的第一个备份将包含以下信息：
INCARNATION# 4
SCN# 400
Time......... 18:00
如果使用上面的脚本查询数据库中的化身，我们将得到如下信息：
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
1 0 1 2017-03-08 15:57:31 PARENT -> 1
2 1 200 2018-07-16 13:20:00 PARENT -> 1 -> 2
3 2 400 2018-07-17 15:20:00 ORPHAN -> 1 -> 2 -> 3
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
发生了什么？我们有一个孤儿！
如果您查看图片，我们目前正站在18:00（6pm）的化身4和SCN 400站在广场上。现在，如果您沿那条线回到起点，您会发现我们将从化身开始4备份到实例2，然后备份到实例1，这是创建数据库的时间。
这也对应于我的脚本的（简化）输出。
INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME STATUS PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
4 2 300 2018-07-17 17:20:00 CURRENT -> 1 -> 2 -> 4
那么化身3发生了什么？化身3是坏的还是陈旧的或产生了什么？
不，化身3还不错，只是孤儿。
在更大的范围内，备份和还原之间需要更多时间，您仍然可以将数据库还原/恢复到化身3世系的某个时间点。您可以关闭以下命令：
RESET DATABASE TO INCARNATION 3;...然后将数据库还原/恢复到该时间点，就像其他还原/恢复数据库一样。
该ORPHAN状态告诉您的是，化身3不再与具有当前化身4的数据库的当前状态相关。不再需要孤立的化身3来沿当前时间线还原/恢复数据库。
现在查看与孤立实例有关的数据库备份，RMAN会确定孤立实例的备份是过时的。但这是一个不同的问答故事...
ORPHAN（如果这是非当前化身而不是当前化身的直接祖先）。
重现步骤：
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393014
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 CURRENT
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
3393975
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393200;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 PARENT
4 CURRENT
SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 394265912 bytes
Database Buffers 662700032 bytes
Redo Buffers 8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;
Flashback complete.
SQL> alter database open resetlogs;
Database altered.
SQL> select incarnation#, status from v$database_incarnation;
INCARNATION# STATUS
------------ -------
1 PARENT
2 PARENT
3 ORPHAN
4 ORPHAN
5 CURRENT