在不完全恢复并打开 9i 数据库后，resetlogs我们运行了一个成功完成的完整备份。备份包含一个命令，用于在完成后删除过时的备份：
delete noprompt obsolete device type sbt;
RMAN 配置为使用 REDUNDANCY 2：
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
然而，旧版本的所有备份都立即标记为过时并删除，而不考虑冗余。
- 如果我们有一个
RECOVERY WINDOW配置而不是，这种行为会有所不同REDUNDANCY 2吗？ - 这种行为在更高版本的 Oracle 中是否相同？
编辑：添加的输出LIST INCARNATION：
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
------- ------- -------- ---------------- --- -------------- ----------
1 1 LIVE 3494832994 NO 1 19-JAN-04
2 2 LIVE 3494832994 NO 11966702870498 01-JAN-14
3 3 LIVE 3494832994 YES 12041003378277 04-JUL-18
对于感兴趣的 RMAN 初学者
RMAN 策略
REDUNDANCY和RECOVERY WINDOW是互斥的。这意味着您可以设置一个或另一个。冗余策略
设置
REDUNDANCY 2将始终仅保留最后两个备份并删除（或标记为过时）任何其他以前的备份，这些备份不再需要使数据库恢复到一致状态。注意：
如果在 FULL 和/或 LEVEL 0 备份之间有 LEVEL 1 和 ARCHIVELOG 备份，则应保留它们直到不再需要。
附加信息
根据 PDF 文件Oracle 数据库 - 备份和恢复参考，您的保留策略
REDUNDANCY 2不应该删除旧备份：上面的示例使用值 1，但清楚地表明完整备份的早期备份不会被删除，直到它们大于配置的值。
回答您的问题
这取决于，....（参见 2. 和“可能的问题”）
根据文档
retention policy，所有版本的设置似乎仍然相同：可能的问题
使用 Oracle 12c 进行复制
因为 Oracle RDBMS 9i 几乎已经过时并且我们的环境几乎是最新的，所以我只能在 12c 环境中重新迭代/重现这些步骤。
RMAN 配置
RMAN 使用默认设置：
RMAN 备份
通过发出一个简单的
backup database;命令来执行 RMAN 备份：验证备份、检查过时的备份和列出化身
在执行了一段时间的备份后，我再次检查了 RMAN 目录：
验证周围没有过时的备份：
并列出了当前的化身：
执行首次还原/恢复
发出以下命令以将数据库恢复/恢复到一致状态：
RMAN> 立即关闭 数据库关闭 数据库已卸载 Oracle 实例关闭 RMAN> 启动挂载； 连接到目标数据库（未启动） Oracle 实例已启动 数据库挂载 总系统全局区域 1610612736 字节 固定大小 8747368 字节 可变大小 385877656 字节 数据库缓冲区 1207959552 字节 重做缓冲区 8028160 字节 RMAN> 运行 2> { 3> 设置到时间'2018-07-17 14:36:14'; 4> 恢复数据库； 5> 恢复数据库； 6>} 执行命令：SET until 子句 2018-07-17 16:04:30 开始恢复 分配通道：ORA_DISK_1 通道 ORA_DISK_1：SID=12 设备类型=DISK 通道 ORA_DISK_1：开始数据文件备份集恢复 通道 ORA_DISK_1：指定要从备份集中恢复的数据文件 通道 ORA_DISK_1：将数据文件 00001 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\SYSTEM01.DBF 通道 ORA_DISK_1：将数据文件 00003 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\SYSAUX01.DBF 通道 ORA_DISK_1：将数据文件 00005 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\UNDOTBS01.DBF 通道 ORA_DISK_1：将数据文件 00007 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\USERS01.DBF 通道 ORA_DISK_1：从备份片 C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\BACKUPSET\2018_07_17\O1_MF_NNND0_TAG20180717T143558_FNVROH49_.BKP 读取 通道 ORA_DISK_1: 块句柄=C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\BACKUPSET\2018_07_17\O1_MF_NNND0_TAG20180717T143558_FNVROH49_.BKP tag=TAG20180717T143558 通道 ORA_DISK_1：恢复的备份片 1 通道 ORA_DISK_1：恢复完成，经过时间：00:00:07 2018-07-17 16:04:38 完成恢复 2018-07-17 16:04:38 开始恢复 使用通道 ORA_DISK_1 开始媒体恢复 媒体恢复完成，经过时间：00:00:00 2018-07-17 16:04:39 完成恢复 RMAN> 改变数据库打开重置日志； 已处理报表 RMAN> 列表化身； 数据库化身列表 DB Key Inc Key DB 名称 DB ID STATUS Reset SCN Reset Time -------- ------- -------- ---- --- --------- - ---------- 1 1 ORACLE12 2083073378 家长 1 2017-03-08 15:57:31 2 2 ORACLE12 2083073378 父 1490582 2018-07-16 09:27:03 3 3 ORACLE12 2083073378 当前 1701490 2018-07-17 16:05:13 RMAN> 列出备份摘要； 备份列表 ================ 密钥 TY LV S 设备类型 完成时间 #Pieces #Copies 压缩标签 ------- -- -- - ----------- ------- -------- - ------ ---------- --- 3 BFA 磁盘 2018-07-16 10:03:01 1 1 无标签20180716T100301 5 BFA 磁盘 2018-07-16 10:27:44 1 1 无标签20180716T102744 7 BFA 磁盘 2018-07-16 10:49:50 1 1 无标签20180716T104950 9 BFA 磁盘 2018-07-16 10:50:08 1 1 无标签20180716T105007 11 BFA 磁盘 2018-07-16 10:50:22 1 1 无标签20180716T105022 13 BFA 磁盘 2018-07-16 10:51:21 1 1 无标签20180716T105121 15 BFA 磁盘 2018-07-16 13:06:13 1 1 无标签20180716T130612 17 BFA 磁盘 2018-07-16 15:26:23 1 1 无标签20180716T152623 19 BFA 磁盘 2018-07-16 15:57:07 1 1 无标签20180716T155707 20 B 0 A 磁盘 2018-07-17 08:22:01 1 1 无标签20180717T082154 21 BFA 磁盘 2018-07-17 08:22:02 1 1 无标签20180717T082202 22 B 0 A 磁盘 2018-07-17 14:36:07 1 1 无标签20180717T143558 23 BFA 磁盘 2018-07-17 14:36:14 1 1 无标签20180717T143614 24 BFA 磁盘 2018-07-17 15:16:15 1 1 无标签20180717T151608 25 BFA 磁盘 2018-07-17 15:16:23 1 1 无标签20180717T151623 26 BAA 磁盘 2018-07-17 15:55:52 1 1 无标签20180717T155551 27 BFA 磁盘 2018-07-17 15:55:53 1 1 无标签20180717T155553 28 BFA 磁盘 2018-07-17 16:05:17 1 1 无标签20180717T160517 RMAN> 报告过时； RMAN 保留策略将应用于命令 RMAN 保留策略设置为冗余 2 未找到过时的备份还原成功，并且没有备份被标记为过时，即使在还原后化身已更改并且已
ALTER DATABASE OPEN RESETLOGS发布。替代化身列表
可以使用以下命令实现化身的替代表示：
输出：
INCARNATION#RESETLOGS_CHANGE#RESETLOGS_TIME PRIOR_INCARNATION#状态等级路径 ------------ ----- ----------- ---------------- -------- ---------- ----- --- 1 1 2017-03-08 15:57:31 0 父母 1 -> 1 2 1490582 2018-07-16 09:27:03 1 父母 2 -> 1 -> 2 3 1701490 2018-07-17 16:05:13 2 当前 3 -> 1 -> 2 -> 3在数据库实例中查询本地目录的优点是将化身表示为要遵循的路径
执行第二次还原/恢复
发出以下命令以再次将数据库恢复/恢复到一致状态：
RMAN> 立即关闭 数据库关闭 数据库已卸载 Oracle 实例关闭 RMAN> 启动挂载 连接到目标数据库（未启动） Oracle 实例已启动 数据库挂载 总系统全局区域 1610612736 字节 固定大小 8747368 字节 可变大小 520095384 字节 数据库缓冲区 1073741824 字节 重做缓冲区 8028160 字节 RMAN> 运行 2> { 3> 设置到时间'2018-07-17 08:22:01'; 4> 恢复数据库； 5> 恢复数据库； 6>} 执行命令：SET until 子句 2018-07-17 16:14:37 开始恢复 分配通道：ORA_DISK_1 通道 ORA_DISK_1: SID=11 设备类型=DISK RMAN-00571：============================================== ============== RMAN-00569：=============== 错误消息堆栈跟随 =============== RMAN-00571：============================================== ============== RMAN-03002：在 2018 年 7 月 17 日 16:14:37 恢复命令失败 RMAN-20207：UNTIL TIME 或 RECOVERY WINDOW 早于 RESETLOGS 时间好的，我们在恢复路径中遇到了一个化身“碰撞”。我们目前处于化身 3，如下面的化身列表所示，我从上面复制了该列表：
INCARNATION#RESETLOGS_CHANGE#RESETLOGS_TIME PRIOR_INCARNATION#状态等级路径 ------------ ----- ----------- ---------------- -------- ---------- ----- --- 1 1 2017-03-08 15:57:31 0 父母 1 -> 1 2 1490582 2018-07-16 09:27:03 1 父母 2 -> 1 -> 2 3 1701490 2018-07-17 16:05:13 2 当前 3 -> 1 -> 2 -> 3...我们的目标是在化身 2 的 RESETLOGS 之后进行备份。让我们将化身重置为 2 并继续备份：
似乎工作。让我们再次重新启动还原/恢复：
RMAN> 运行 2> { 3> 设置到时间'2018-07-17 08:22:01'; 4> 恢复数据库； 5> 恢复数据库； 6>} 执行命令：SET until 子句 2018-07-17 16:16:12 开始恢复 使用通道 ORA_DISK_1 通道 ORA_DISK_1：开始数据文件备份集恢复 通道 ORA_DISK_1：指定要从备份集中恢复的数据文件 通道 ORA_DISK_1：将数据文件 00001 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\SYSTEM01.DBF 通道 ORA_DISK_1：将数据文件 00003 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\SYSAUX01.DBF 通道 ORA_DISK_1：将数据文件 00005 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\UNDOTBS01.DBF 通道 ORA_DISK_1：将数据文件 00007 恢复到 C:\ORACLE_12\ORADATA\ORACLE12JN\USERS01.DBF 通道 ORA_DISK_1：从备份片 C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\BACKUPSET\2018_07_17\O1_MF_NNND0_TAG20180717T082154_FNV2R328_.BKP 读取 通道 ORA_DISK_1: 块句柄=C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\BACKUPSET\2018_07_17\O1_MF_NNND0_TAG20180717T082154_FNV2R328_.BKP tag=TAG20180717T082154 通道 ORA_DISK_1：恢复的备份片 1 通道 ORA_DISK_1：恢复完成，经过时间：00:00:07 于 2018-07-17 16:16:20 完成恢复 2018-07-17 16:16:20 开始恢复 使用通道 ORA_DISK_1 开始媒体恢复 具有序列 3 的线程 1 的归档日志已作为文件 C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\ARCHIVELOG\2018_07_17\O1_MF_1_3_FNVXC7R7_.ARC 在磁盘上 归档日志文件名=C:\ORACLE_12\RECOVERY_AREA\ORACLE12JN\ARCHIVELOG\2018_07_17\O1_MF_1_3_FNVXC7R7_.ARC 线程=1 序列=3 媒体恢复完成，经过时间：00:00:00 于 2018-07-17 16:16:21 完成恢复 RMAN> 改变数据库打开重置日志； 已处理报表 RMAN> 报告过时 2>; RMAN 保留策略将应用于命令 RMAN 保留策略设置为冗余 2 未找到过时的备份 RMAN>还原成功并且没有备份被标记为过时，即使在还原之后化身发生了变化并且
ALTER DATABASE OPEN RESETLOGS再次发出了 。现在我们是一个更新的化身，仍然没有Obsolete Backups报告。第二次还原后的当前化身列表 (SQL)
SQL> select INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, PRIOR_INCARNATION#, STATUS, LEVEL, 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# RESETLOGS_CHANGE# RESETLOGS_TIME PRIOR_INCARNATION# STATUS LEVEL PATH ------------ ----------------- ------------------- ------------------ ------- ---------- -------------------- 1 1 2017-03-08 15:57:31 0 PARENT 1 -> 1 2 1490582 2018-07-16 09:27:03 1 PARENT 2 -> 1 -> 2 3 1701490 2018-07-17 16:05:13 2 ORPHAN 3 -> 1 -> 2 -> 3 4 1691865 2018-07-17 16:16:29 2 CURRENT 3 -> 1 -> 2 -> 4Initiate Backup
After restoring the second time let's backup the database again:
Check Obsolete
We'll now check which (backup) files have become obsolete:
Check Incarnations (SQL)
SQL> select INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, PRIOR_INCARNATION#, STATUS, LEVEL, 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# RESETLOGS_CHANGE# RESETLOGS_TIME PRIOR_INCARNATION# STATUS LEVEL PATH ------------ ----------------- ------------------- ------------------ ------- ---------- -------------------- 1 1 2017-03-08 15:57:31 0 PARENT 1 -> 1 2 1490582 2018-07-16 09:27:03 1 PARENT 2 -> 1 -> 2 3 1701490 2018-07-17 16:05:13 2 ORPHAN 3 -> 1 -> 2 -> 3 4 1691865 2018-07-17 16:16:29 2 CURRENT 3 -> 1 -> 2 -> 4As can be seen the incarnation 3 is now orphaned, because its direct line of heritage in regards to the current state of the database is broken. After the first restore we went back in time an re-restored the database again which results in the incarnation path
1 -> 2 -> 4being the direct line of current ancestors for the open database.Because the direct line for restoring the current database is along the incarnations of 1, 2, 4 there is no need for RMAN to keep the obsolete backups listed above. They can safely be deleted.
Delete Obsolete
Let's go ahead and delete the obsolete backups:
List Backup Summary
Now that we have deleted some backup files and RMAN has performed some internal cleaning, let's have a look at the backup summary:
As we can see we still have "at least" two complete backup that will allow us to restore the database two backups in the past. RMAN (in 12c) did not delete any other backups along the incarnation path or outside of the orphaned incarnation.
Conclusion
Regarding the deleted backups after your initial restore in 9i I believe there are two possible scenarios:
Reference Material
从我的头顶。化身设置为防止您恢复太旧的备份。这样他们就过时了。
但是，您仍然可以使用它们来恢复，但在这种情况下，您需要自己将化身更改为“以前的”化身。同时，您的最新备份已过时。
这种行为仍然相同。