下面是一个简短的图形，我将用它来解释何时在数据库的化身中创建孤儿。这是我在回答问题时用来解释化身的图形的变体谁能以易于理解的方式向我解释 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 单击以启动来自 3rd 方供应商的恢复/恢复。
RMAN 从磁盘/磁带检索数据库的完整备份和所有存档日志备份，并将它们还原到磁盘。在恢复阶段，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;
数据库的当前版本将类似于：
ALTER DATABASE OPEN RESETLOGS;
使用图形我们可以看到，我们已经从包含化身 1 的路径移动到包含化身 2 的路径，因为我们已经打开了数据库，RESETLOGS并且数据库已经创建了一个新的化身。
让我们再次假设数据库在第一次恢复/恢复操作后继续运行，并且在 15:00（下午 3 点）之后有人决定需要在同一天的 15:00（下午 3 点）将新的恢复/恢复恢复到整小时。
RMAN 将还原文件、恢复数据库并启动ALTER DATABASE OPEN RESETLOGS使数据库重新联机的操作。INCARNATION# 现在将设置为 3，16:00 的第一个备份将包含以下信息：
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
让我们再次假设数据库在第二次恢复/恢复操作后继续运行，并且在 17:00（下午 5 点）之后有人决定需要在同一天的 14:00（下午 2 点）进行新的恢复/恢复。
RMAN 将还原文件、恢复数据库并启动ALTER DATABASE OPEN RESETLOGS使数据库重新联机的操作。INCARNATION# 现在将设置为 4，18: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
发生了什么事？我们有一个孤儿！
如果你看图表，我们目前在 18:00（下午 6 点）与 Incarnation 4 和 SCN 400 站在广场上。现在如果你沿着这条线回到开头，你会看到我们将从化身开始4 备份到化身 2，然后再回到化身 1，即创建数据库的时间。
这也对应于我的脚本的（简化的）输出。
INCARNATION# 4
SCN# 400
Time......... 18:00
那么转世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
| 归档时间： |
|
| 查看次数： |
4820 次 |
| 最近记录： |