诊断和响应故障_RMAN数据修复概念

1．RMAN数据修复概述

1.1．关于需要数据修复的问题

虽然有几种问题会中止Oracle数据库的正常操作或影响数据库I/O操作，只有以下几种情况要求DBA介入和数据修复：用户错误，应用程序错误和介质故障。

1.1.1．关于用户错误

由于应用程序逻辑错误或人为错误，数据库中的数据被错误更改或删除时用户错误发生。

例如，用户登录错误的数据库和删除数据库表。用户错误被预计是导致数据库停机的最大的原因。

1.1.2．关于应用程序错误

有时候软件发生故障会损坏数据块。在物理损坏中，也被称为介质损坏，数据库不能识别块。

1.1.3．关于介质故障

当正常操作过程中外部的问题阻止数据库读取或写入文件时介质故障发生。

典型的介质故障包括磁盘故障和数据文件删除。介质故障比用户或应用程序错误更少见，但备份和恢复策略需要为它们准备。

1.2．关于RMAN数据修复技术

RMAN提供多种数据修复的方法。

取决于你预料的情形，考虑将下表中描述的每个选项都包含在数据丢失的响应策略中，然后设置数据库让这些选项是可能的。

数据修复技术	描述
Data Recovery Advisor（数据恢复顾问）	这个Oracle数据库基础结构可以诊断故障，建议如何响应它们和自动修复故障。
逻辑闪回特性	Oracle闪回技术特性的子集让你可以查看和倒回个别的数据库对象或事务到一个过去的时间。这些特性不需要使用RMAN。
Oracle闪回数据库	闪回数据库是与介质恢复类似的块级别的恢复机制，但一般更快和不需要还原备份。如果预先启用了闪回日志，可以返回整个数据库到一个之前的状态而不需要从备份中还原数据文件的旧副本。必须为闪回数据库的日志或保证还原点配置一个快速恢复区域。
数据文件介质恢复	这种介质恢复形式让你还原数据文件备份和应用归档redo日志或增量备份来恢复丢失的更改。可以恢复整个数据库或数据库的子集。数据文件介质恢复是最通用的恢复形式，可以防范物理和逻辑故障。
块介质恢复	这种介质恢复形式让你恢复数据文件中的个别块而不是整个数据文件。
表空间时间点恢复（TSPITR）	这是一个时间点恢复的专业的形式，可以恢复一个或多个表空间到比数据库的其它部分更早的时间。

2．关于RMAN还原（Restore）操作

在RMAN的还原操作中，可以选择要还原的文件，然后运行RESTORE命令。典型地，还原文件为介质恢复做准备。

可以还原以下文件类型：
1）数据库（所有数据文件）
2）表空间
3）控制文件
4）归档redo日志
5）spfile

可以为还原的数据文件和控制文件指定缺省位置或新的位置。如果还原到缺省位置，那么RMAN覆盖在这个位置中当前存在的相同名称的任何文件。或者，可以使用SET NEWNAME命令来为还原的的数据文件指定新的位置。然后运行SWITCH命令来更新控制文件来标示在新位置中的还原文件现在是当前的数据文件。

2.1．关于RMAN备份选择

RMAN使用在RMAN仓库中的可用的备份集或映像副本的记录来选择最佳的可用备份在还原操作中使用。

最近的可用备份或满足RESTORE命令中的任何UNTIL子语句的最近的备份，是优先的选择。如果两个备份来自同一个时间点，那么RMAN优先选择映像副本而不是备份集，因为RMAN可以从映像副本中比备份集（特别是存储在磁带上的）更快地还原。

在RMAN还原备份之前必须满足RESTORE命令的所有技术说明。除非被DEVICE TYPE子语句限制，RESTORE命令搜索配置的通道的所有设备类型上的备份。如果仓库中没有可用的备份满足所有指定的条件，那么RMAN返回一个错误指示文件不能被还原。

如果只使用手动分配的通道，那么如果在分配的通道的介质上没有可用的备份，备份作业可能会失败。配置自动通道让RMAN更可能可以找到和还原满足指定条件的备份。

2.2．关于RMAN还原故障切换（Restore Failover）

RMAN自动使用还原故障切换来跳过损坏的或不能访问的备份，寻找可用的备份。当备份不能找到时或包含损坏的数据，RMAN自动寻找另一个备份来还原期望的文件。

RMAN生成消息标示执行的故障切换（failover）的类型。例如，当RMAN故障切换到同一个文件的另外一个备份，它产生类似以下的消息：

failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009

如果没有能用的副本可用，那么RMAN搜索之前的备份。产生的消息类似以下示例：

ORA-19624: operation failed, retry possible
ORA-19505: failed to identify file "/u01/backup/db_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
failover to previous backup

RMAN重复执行还原故障切换（failover）直到它耗尽所有可能的备份。如果所有的备份不可用或没有备份存在，那么RMAN尝试重建数据文件。还原故障切换也在RECOVER，RECOVER … BLOCK和FLASHBACK DATABASE命令过程中还原归档redo日志出现错误时使用。

2.3．关于RMAN还原操作和ASM

当使用ASM磁盘组时，RMAN还原操作只有在数据文件的全名，包括转生（incarnation）与存在的数据文件名称不匹配时才创建数据文件的新副本。

一个完全合格的ASM文件名称是这样的形式+diskgroup/dbname/filetype/filetypetag.file.incarnation。当首先还原控制文件，然后还原其它数据库文件时，控制文件中的数据文件名称可能与存在的数据文件名称不匹配，因此数据文件会重建。

使用以下一种方法来确保存在的数据文件在还原或复制操作过程中不会重建：
1）在控制文件中，为每个数据文件使用别名。别名必须不能包含ASM转生数字（incarnation number）。
2）在还原控制文件之后和还原其它数据文件之前，使用CATALOG命令确保存在的数据文件登记在还原的控制文件中。下一步，使用SWITCH命令让还原的控制文件指向存在的数据文件。
3）在还原数据文件之前和还原控制文件之后，使用SET NEWNAME来重命名数据文件。

2.4．关于RMAN还原优化

RMAN使用还原优化来尽可能地避免从备份中还原数据文件。如果数据文件在正确的位置存在和它的头部包含预期的信息，那么RMAN不从备份中还原数据文件。

注：还原优化只检查数据文件的头部。它不会扫描数据文件的主体来查找损坏块。

可以使用RESTORE命令的FORCE选项来覆盖这种行为和无条件还原请求的文件。

当还原几个数据文件的操作中断时，还原优化特别有用。例如，假设完全数据库恢复在除了一个数据文件之外其它都已经还原时遇到电源故障。如果再次运行相同的RESTORE命令，那么RMAN只还原在之前的尝试过程中没有还原的这个单一的数据文件。

还原优化在复制数据库时也可以使用。如果在复制的一个数据文件在正确的位置和有正确的头部内容，那么数据文件不被复制。不像RESTORE，DUPLICATE不支持FORCE选项。为了强制RMAN复制由于还原优化而跳过的数据文件，在运行DUPLICATE命令之前从副本中删除数据文件。

3．关于RMAN介质恢复（Media Recovery）

在介质恢复中，RMAN应用更改到还原的数据在时间上向前滚动数据。

RMAN可以执行数据文件介质恢复或块介质恢复。

数据文件介质恢复是应用redo日志或增量备份到还原的数据文件来更新它到当前时间或某些其它指定的时间。可以使用RMAN执行完全恢复，数据库时间点恢复（DBPITR），表空间时间点恢复（TSPITR）。可以使用RESTORE命令来还原丢失和损坏的数据文件或控制文件的备份和RECOVER命令来执行介质恢复。

块介质恢复是个别数据块而不是整个数据文件的恢复。

这部分只阐述数据文件介质恢复。块介质恢复是介质恢复的一种专业的形式，在“块介质恢复概述”中讲述。

3.1．关于增量备份和归档redo日志的选择

RMAN自动化介质恢复。RMAN在无论哪种最有效的组合中自动还原和应用增量备份和归档redo日志。

如果RMAN仓库指示要求的日志序列号副本在磁盘上不存在时，那么它自动从备份中还原要求的日志。缺省情况下，RMAN还原归档日志到快速恢复区域，如果归档目标设置为USE_DB_RECOVERY_FILE_DEST的话。否则，RMAN还原日志到初始化参数文件中第一个本地的归档目的地。

3.2．关于数据库转生（Database Incarnation）

无论何时使用RESETLOGS选项打开数据库时会创建新的数据库转生。

在完全的介质恢复之后，可以恢复正常的操作而不需要OPEN RESETLOGS。然而，在DBPITR或使用备份的控制文件恢复之后，必须使用RESETLOGS选项打开数据库，从而创建数据库的一个新转生。数据库要求一个新的转生来避免两个不同的redo流具有相同的SCN，但发生在不同的时间所引起的混淆。如果应用错误的redo到数据库，那么会损坏它。

一个单一的数据库的多个转生的存在决定了RMAN如何对待不在当前转生路径的备份。通常，当前的数据库转生是正确的可以使用的转生。然而，在某些情况中重置数据库到一个之前的转生是最佳方法。例如，你可能不满意已经执行的时间点恢复的结果，想返回数据库到RESETLOGS之前的一个时间。了解数据库转生为这些情形准备是有帮助的。

3.2.1．关于RMAN OPEN RESETLOGS操作

当使用RESETLOGS选项打开数据库时，RMAN执行某些操作。

执行的操作如下：
1）归档当前的在线redo日志（如果可以访问），然后擦除在线redo日志的内容，重置日志序列号为1。
例如，当使用RESETLOGS打开数据库时，如果当前在线redo日志是序列1000和1001，那么数据库归档日志1000和1001，然后重置在线redo日志为序列1和2。
2）如果当前不存在，创建在线redo日志文件。
3）初始化控制文件中的redo线程记录和在线redo日志记录到新数据库转生的开端。
更具体来说，数据库设置redo线程状态为关闭，设置redo线程记录中的当前线程序列为1，设置每个redo线程的线程检查点为日志序列1的开端，从每个线程选择一个redo日志，初始化它的序列为1等。
4）使用新的RESETLOGS SCN和时间戳更新所有当前的数据文件和在线redo日志和所有接下来的归档redo日志。

因为数据库不应用归档redo日志到数据文件除非RESETLOGS SCN和时间戳匹配，RESETLOGS要求阻止你使用不是来自当前转生的直接父转生（direct parent incarnation）的归档日志损坏数据文件。转生之间的关系在下面的章节会更完整地说明。

在以前的版本中，建议在OPEN RESETLOGS之后立即备份数据库。因为现在可以像任何其它备份一样轻松地恢复一个RESETLOGS之前的备份，做一个新的数据库备份是可选的。为了越过RESETLOGS执行恢复，必须拥有在最近的备份之后生成的所有归档日志和至少一个控制文件（当前的，备份的或创建的）。

3.2.2．数据库转生之间的关系

数据库转生之间可以处于如下的关系：
1）当前转生（current incarnation）是数据库当前正在运行的转生。
2）在OPEN RESETLOGS操作之后当前转生分支的原转生是当前转生的父转生（parent incarnation）。
3）父转生的父转生是祖先转生（ancestor incarnation）。祖先转生的任何父转生也是当前转生的祖先转生。
4）当前转生的直接祖先路径（direct ancestral path）以最早的转生开始，只包括到当前转生的祖先，父转生或当前转生的分支。

转生序号用来唯一地标记和鉴别redo流。下图描述数据库经过几个转生，每个都有一个不同的转生序号。

数据库的转生1从SCN 1开始，继续通过SCN1000到SCN2000。假设在转生1的SCN 2000时，向后执行时间点恢复到SCN 1000，然后使用RESETLOGS选项打开数据库。转生2现在以SCN 1000开始，继续到SCN 3000。在这个示例中，转生1是转生2的父亲。

假设在转生2的SCN 3000时，执行时间点恢复到SCN 2000，使用RESETLOGS选项打开数据库。在这个示例中，转生2是转生3的父亲。转生1是转生3的祖先。

当DBPITR或闪回数据库在数据库中发生时，一个SCN会涉及到多个时间点，取决于哪个转生是当前的。例如，上图中的SCN 1500涉及到转生1或转生2的SCN。

可以使用RESET DATABASE TO INCARNATION命令来指定SCN在一个特定的数据库转生的坐标（frame of reference）中被解释。当使用FLASHBACK，RESTORE或RECOVER来返回到一个非当前的数据库转生中的SCN时，命令RESET DATABASE TO INCARNATION是必需的。不过，RMAN在执行FLASHBACK时内含地执行命令RESET DATABASE TO INCARNATION。

3.2.3．关于孤儿备份（Orphaned Backups）

当数据库经过多个转生时，某些备份变成孤儿备份。孤儿备份是在不在直接祖先路径中的数据库转生过程中创建的备份。

假设Figure 14-1中显示的场景。如果转生3是当前的转生，那么以下备份是孤儿的：
1） 转生1在SCN 1000之后的所有备份
2） 转生2在SCN 2000之后的所有备份

相反，以下备份不是孤儿备份，因为它们在直接祖先路径上：
1） 转生1在SCN 1000之前做的所有备份
2） 转生2在SCN 2000之前做的所有备份
3） 转生3的所有备份

当你想还原数据库到一个不在直接祖先路径的SCN时，可以使用孤儿备份。如果从最早的备份到你想恢复的点的持续路径的归档日志存在，RMAN可以从父和祖先转生中还原备份和恢复到当前时间，即使跨越OPEN RESETLOGS操作。如果从表现在备份中的更改没有被丢弃的转生中还原控制文件，那么RMAN也可以还原和恢复孤儿备份。

来源：《Oracle Database Backup and Recovery User’s Guide，19c》