- 还原和恢复
备份和恢复任务的“恢复”部分包括的活动有两种主要类型：还原和恢复。“还原”文件是指将备份复制到位以供数据库使用的过程。 例如，如果由于文件所在的物理磁盘出现故障而使文件受损，则还原文件是必要的。出现这种情况通常是由于硬件问题，如磁盘写入错误或控制器故障。在这种情况下，需要将文件备份复制到新的（或已修复的）磁盘上。 “恢复”文件需要应用重做，以便将文件的状态恢复到所需的任何时间点。该点通常应尽可能地接近故障时间。在数据库行业中，这两个操作通常全部用一个术语“恢复”来指代。
- 文件丢失的原因
- 关键性与非关键性
- 自动恢复临时文件
- 日志组状态：综述
sys@TEST0924> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ -------------------
1 1 106 52428800 512 1 YES ACTIVE 2521086 2013-10-06:12:00:44 2527386 2013-10-06:13:23:25
2 1 107 52428800 512 1 NO CURRENT 2527386 2013-10-06:13:23:25 2.8147E+14
3 1 105 52428800 512 1 YES INACTIVE 2508844 2013-10-06:10:00:12 2521086 2013-10-06:12:00:44
- 在丢失了重做日志组后进行恢复
在丢失了重做日志组后进行恢复 如果丢失了整个重做日志组，则该组的所有日志文件副本都是无法使用的或已丢失。 最简单的情况就是重做日志组处于INACTIVE状态。这意味着，当前没有向重做日志组写入数据，且不再需要它来恢复实例。如果该问题是临时的，或者用户可以修复介质，则数据库将继续正常运行，在发生足够的日志切换事件后将重用该组。否则，如果无法修复介质，则可以清除日志文件。清除日志文件即表明可以重用该文件。 如果有问题的重做日志组处于ACTIVE状态，则即使当前没有向该重做日志组写入数据，执行实例恢复时也仍然需要它。如果可以执行检查点，则不再需要该日志文件组来恢复实例，用户可以继续操作，就好像该组处于非活动状态一样。 如果该日志组处于CURRENT状态下，则表示在该日志组丢失时，正在向其中写入数据。在这种情况下，用户甚至可能看到LGWR 进程失败。如果发生这种情况，则实例将崩溃。此时的唯一选择就是从备份还原，执行基于取消的时间点恢复，然后使用RESETLOGS选项打开数据库。
- 清除日志文件
清除日志文件 可使用以下命令清除日志文件：ALTER DATABASE CLEAR [UNARCHIVED] LOGFILE GROUP <n> [UNRECOVERABLE DATAFILE] 清除日志文件即表明可以重用该文件。如果日志文件已归档，则可以使用该命令的最简单的形式。使用以下查询可确定哪些日志组已归档：SQL> SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG; 例如，以下命令可清除已归档的重做日志组3：SQL> ALTER DATABASE CLEAR LOFGILE GROUP 3; 如果尚未归档重做日志组，则必须指定UNARCHIVED关键字来清除日志文件。这用于用户确认可能存在依赖于该重做日志进行恢复的备份，并且你决定放弃该恢复机会。这可能是所需要的，尤其是在纠正重做日志组问题后立即执行其它备份，不再需要该重做日志文件时。可能需要使用重做日志才能恢复当前处于脱机状态下的数据文件。
- 丢失了索引表空间后进行恢复
- 重新创建索引
- 面向数据库管理员的验证方法
面向数据库管理员的验证方法根据是希望在数据库所在的那一台计算机上本地管理数据库，还是希望从一个远程客户机管理许多不同的数据库服务器，可以选择使用操作系统验证或口令文件验证来验证数据库管理员：• 如果数据库具有口令文件且你已经具有SYSDBA或SYSOPER系统权限，则可以通过口令文件进行验证。• 如果服务器未使用口令文件，或者你不具有SYSDBA或SYSOPER权限因而不在口令文件中，则可以使用操作系统验证。 在大多数操作系统中，数据库管理员的验证需要将数据库管理员的操作系统用户名放置到一个特殊组中，一般称为OSDBA。 该组中的用户将被授予SYSDBA权限。一个类似的组OSOPER用于向用户授予SYSOPER权限。 操作系统验证优先于口令文件验证。特别是，如果你是操作系统的OSDBA或OSOPER组的成员，并且以SYSDBA或SYSOPER身份连接，则连接你您将具有相关的管理权限，而与你指定的用户名/口令无关。
- 重新创建口令验证文件
- 比较完全恢复和不完全恢复
恢复有两类作用域：• 完全恢复：将数据库恢复到当前最新状态，包括直至请求恢复时进行的所有已提交的数据更改• 不完全或时间点恢复：将数据库恢复到请求恢复操作之前指定的过去时间点 比较完全恢复和不完全恢复 执行完全恢复时，数据库会完全恢复到最新状态，包括到当前为止提交的所有数据修改。但是执行不完全恢复时，数据库会恢复到过去时间点的某个点。它还被称为“数据库时间点恢复”。 这意味着会缺失一些事务处理；即恢复目标时间和当前时间之间所做的所有数据修改都会丢失。 在很多情况下，这正是想要的结果，因为可能需要撤消对数据库进行的一些更改。恢复到过去的某一时间点是删除误更改的一种方法。
- 完全恢复过程
完全恢复过程下面的步骤说明了执行完全恢复期间要采取的操作：1. 通过备份还原损坏或缺失的文件。2. 根据需要应用增量备份、归档重做日志文件和联机重做日志文件中的更改。将重做日志更改应用于数据文件，直到到达当前联机日志，并且重新输入了最新的事务处理。在整个过程中会生成还原块。这称为前滚或高速缓存恢复。3. 此时，还原的数据文件中包含已提交和未提交的更改。4. 还原块用于回退任何未提交的更改。有时也称为事务处理恢复。5. 此时，数据文件处于已恢复状态，且与数据库中的其它数据文件一致。
- 时间点恢复过程
时间点恢复过程不完全恢复或数据库时间点恢复使用备份来生成非当前版本的数据库。也就是说，不会应用最新备份之后生成的所有重做记录。仅当绝对必要时才执行此类恢复。要执行时间点恢复，你需要：• 恢复点之前生成的所有数据文件的有效脱机或联机备份• 从备份时间到指定恢复时间的所有归档日志 下面列出了执行时间点恢复的过程：1. 从备份还原数据文件：如果还原点目标并不很新，则使用的备份可能也不是最新的。这需要使用OS 命令或RMAN RESTORE命令来复制文件。2. 使用RECOVER命令：从归档重做日志文件应用重做，根据需要包括尽可能多的数据以达到还原点目标。3. 恢复以后的状态：此时，数据文件包含一些已提交的事务处理和未提交的事务处理，因为重做可以包含未提交的数据。4. 使用ALTER DATABASE OPEN命令：应用还原之前数据库已打开。这是为了提供更高的可用性。5. 应用还原数据：应用重做时，同时会应用支持还原数据文件的重做。这样，还原可以应用于数据文件，以便还原任何未提交的事务处理。这是接下来要完成的操作。6. 过程完成：此时，数据文件已恢复到所选择的时间点。 如果必须执行恢复且发现包含事务处理的归档日志丢失，其中的事务处理是在还原所用的备份的创建时间与目标恢复SCN 之间发生的，则时间点恢复是唯一的选择。没有丢失的日志，则没有该期间内对数据文件进行更新的记录。唯一的选择就是从还原备份的时间点恢复数据库，直到未损坏的归档日志系列所允许的时间点，然后使用RESETLOGS选项打开数据库。缺失的重做日志文件中的或之后的所有更改都将丢失。
- 恢复只读表空间
- 恢复NOLOGGING数据库对象
QL> CREATE TABLE sales_copy NOLOGGING;SQL> INSERT /*+ APPEND */ INTO sales_copy2 SELECT * FROM sales_history; 恢复NOLOGGING数据库对象利用表和索引的NOLOGGING属性提高效率（如果可以）。创建表作为NOLOGGING时，会向重做流中写入极少的重做数据，以支持对象的创建。这对于加快大型插入非常有用。 在上面的示例中，创建SALES_COPY表作为NOLOGGING表。因此，在按照APPEND提示完成插入时，不会针对特定的插入语句生成重做。因此，您无法在SALES_HISTORY表中恢复此事务处理。如果这是个问题，应立即对以这种方式填充的表创建备份，这一点非常重要。然后，你可以转到该表的最新备份。如果执行介质恢复，并且涉及到NOLOGGING对象，则在恢复过程中会将这些对象标记为逻辑损坏。 在这种情况下，请删除NOLOGGING对象并重新创建这些对象。使用REPORT UNRECOVERABLE RMAN 命令列出任何包含一个或多个对象的表空间名称，从该表空间的最新备份起，已为表空间中的对象执行NOLOGGING操作。
- 在丢失了所有控制文件副本后进行恢复：概览
在丢失了所有控制文件副本后进行恢复：概览丢失了所有的控制文件不应再发生。预防优于恢复。即使你将控制文件副本存储在不同位置，仍有可能需要在丢失了所有这些副本后进行恢复。如果丢失了当前控制文件的所有副本，但拥有备份控制文件，则操作过程取决于联机日志文件和数据文件的状态。上图表显示了每种情况下应执行的操作。 联机日志可用如果联机日志可用且包含恢复所必需的重做，且数据文件是最新的，则可以还原备份控制文件，执行完全恢复，并使用RESETLOGS选项打开数据库。恢复期间，必须指定联机重做日志的文件名。如果数据文件不是最新的，请执行相同的过程。 联机日志不可用如果联机日志不可用，但数据文件是最新的，请重新创建控制文件并打开RESETLOGS。但是，如果数据文件不是最新的，请还原备份控制文件，执行时间点恢复，并打开RESETLOGS。
- 将控制文件恢复到默认位置
将控制文件恢复到默认位置 如果需要恢复控制文件，且默认位置仍为有效位置，请按石头中所示的步骤执行操作。必须先关闭数据库，然后修复任何硬件故障，使默认位置是有效位置。将控制文件还原到默认位置。 使用如下命令执行此操作，将备份控制文件复制到默认位置：% cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf% cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf 装载数据库，并启动恢复过程。必须指定所使用的备份控制文件。 SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; 如果在恢复过程中，系统提示存在缺失的重做日志，这可能表示缺失的重做日志是联机重做日志文件。看到提示时，请提供联机重做日志文件的名称。恢复完成后，请打开数据库，指定RESETLOGS选项。