在Oracle文档描述化身为：
化身
一个单独的数据库版本。使用 RESETLOGS 选项打开数据库时，数据库的化身会发生变化，但只要有必要的重做可用，您就可以从先前的化身恢复备份。
但我仍然不能完全理解它。谁能用通俗易懂的方式给我解释一下？
谢谢，
以下是一个简短的图形，我将用它来解释答案中使用的化身：
restore db +-----+ +-----+ +-----+
recover db | 2>3 | --------> | 3 | --> | 3 | -->
resetlogs +-----+ +-----+ +-----+
^ Incarn. 3 3
/ SCN # 400 500
/
/
restore db +-----+ +-----+ +-----+
recover db | 1>2 | -------> | 2 | --> | 2 | --> ...
resetlogs +-----+ +-----+ +-----+ ^
^ Incarn. 2 2 | 2
/ SCN # 300 400 | 500
/ |
/ |
+-----+ +-----+ +-----+ |
--> | 1 | --> | 1 | --> | 1 | --> ... |
+-----+ +-----+ +-----+ ^ |
Incarn. 1 1 1 | 1 |
SCN # 100 200 300 | 400 |
| |
Backup 11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00
| |
Restore/ (1) (2)
Recovery
创建 Oracle 数据库时，它会收到一个初始化身编号。化身编号存储在数据库本身、数据库实例的控制文件和中央 RMAN 目录数据库中（如果有的话）。
让我们来看看上面的图形。这是对 Oracle 用来解释什么是化身的图形的轻微修改。
参考：RMAN 介质恢复（Oracle 文档）
现在让我们假设存档日志备份每小时发生一次。哦，数据库处于ARCHIVE_LOGS模式，它允许我们备份和恢复存档日志，使我们能够将数据库恢复到某个时间点。我们还将假设数据库在同一天的 04:00 (am) 收到了完整备份。此外，数据库从未恢复，因为它是最初创建的，并且数据库的当前 INCARNATION# 位于1。
我们将进一步假设每小时发生 100 次交易，以便在备份时 SCN# 将是 100 的倍数。
现在只是为了增加图形的可读性。它有助于理解 Oracle 为何为已恢复到某个时间点的数据库创建新的化身。
在 13:00（下午 1 点）之后的某个地方，有人决定必须将数据库恢复到 12:00（中午 12 点）。DBA 要么使用一组 RMAN 命令将数据库恢复到那个时间点，我们通过一个奇妙的 GUI 单击以启动来自 3rd 方供应商的恢复/恢复。
RMAN 从磁盘/磁带检索数据库的完整备份和所有存档日志备份，并将它们还原到磁盘。在恢复阶段，RMAN 会检查所有相关信息是否可用，并将所有完成的事务前滚到 Point-in-Time 并将所有未完成的事务回滚到 Point-in-Time，以确保数据库处于一致的状态。状态。
在数据库向公众开放之前，数据库必须确保所有未来的备份不会与以前的备份发生冲突。这是应该创建新的化身的时候，当您执行以下命令打开数据库时会发生这种情况：
ALTER DATABASE OPEN RESETLOGS;
好的。如果您查看图形，原始 INCARNATION# 1 路径中 13:00（下午 1 点）的 SCN# 是 300。我们从未到达 14:00（下午 2 点）的备份，它会记录 SCN# 400备份。在还原/恢复过程中，不会发生任何备份，并且（假设）如果还原过程需要一个小时，则不会插入新数据。当数据库准备好重新联机并且下一次备份发生在 14:00（下午 2 点）时，备份将包含 SCN# 300。这与启动还原/恢复之前的数据库 SCN# 相同，这是在 13:00（下午 1 点）为备份记录的。
这就是将 INCARNATION# 设置为新值的原因。它允许 Oracle 区分 13:00（下午 1 点）的存档日志备份与以下信息：
INCARNATION# 1
SCN# 300
Time......... 13:00
...以及 14:00（下午 2 点）的备份，其中包含以下信息：
INCARNATION# 2
SCN# 300
Time......... 14:00
假设数据库在第一次恢复/恢复操作后继续运行，并且在 15:00（下午 3 点）之后有人决定需要在同一天的 14:00（下午 2 点）进行新的恢复/恢复。
RMAN 将还原文件、恢复数据库并启动ALTER DATABASE OPEN RESETLOGS使数据库重新联机的操作。INCARNATION# 现在将设置为 3，16:00 的第一个备份将包含以下信息：
INCARNATION# 3
SCN# 400
Time......... 16:00
...否则会与 15:00（下午 3 点）在 INCARNATION#2 和 SCN#400 的数据库备份冲突。但是，由于新的 INCARNATION# 一切正常。
这就是（虽然简短）对化身用途的解释。它允许 RMAN（和英勇的 DBA）确定采取哪条路径来恢复和恢复以前多次备份和恢复的数据库。
这种对转世的简短解释绝不是完整的。还有其他因素会导致ORPHANED化身和OBSOLETE备份。其中一些主题将在本主题或单独的问答中的后续回答中进行讨论。
在更大的时间尺度上查看化身时，还原和恢复可能需要您RESET DATABASE TO INCARNATION <number>在开始恢复数据库之前启动，因为您可能正在将数据库还原和恢复到位于INCARNATION# 1 的路径，它可能需要您恢复控制文件的 AUTOBACKUP 副本，然后才能开始考虑恢复和恢复数据库。
敬请关注...