• 描述文件丢失的原因并确定相应的
• 描述主要的恢复操作
• 备份和恢复控制文件
• 在丢失了重做日志组后进行恢复
- 还原和恢复
备份和恢复任务的“恢复”部分包括的活动有两种主要类型：还原和恢复。
“还原”文件是指将备份复制到位以供数据库使用的过程。
例如，如果由于文件所在的物理磁盘出现故障而使文件受损，则还原文件是必要的。
出现这种情况通常是由于硬件问题，如磁盘写入错误或控制器故障。
在这种情况下，需要将文件备份复制到新的（或已修复的）磁盘上。
“恢复”文件需要应用重做，以便将文件的状态恢复到所需的任何时间点。
该点通常应尽可能地接近故障时间。
在数据库行业中，这两个操作通常全部用一个术语“恢复”来指代。
- 文件丢失的原因
以下原因可能会导致文件丢失：
• 用户错误
• 应用程序错误
• 介质故障
文件丢失的原因
以下原因可能会导致文件丢失或损坏：
• 用户错误：管理员可能因疏忽而删除或覆盖了必需的操作系统文件。
• 应用程序错误：应用程序或脚本也可能包含逻辑错误，当它处理数据库文件时，会导致文件丢失或损坏。
• 介质故障：磁盘驱动器或控制器可能会完全或部分发生故障，从而导致文件损坏，甚至文件完全丢失。
- 关键性与非关键性
非关键性文件丢失是指数据库可以继续运行的故障。
通过执行以下操作之一，可以解决该问题：
• 创建一个新文件。
• 重建文件。
• 恢复丢失或损坏的文件。
关键性与非关键性
非关键性文件是指数据库和大多数应用程序没有它也能继续运行的文件。
例如，如果数据库丢失了一个多路复用重做日志文件，仍可使用其它重做日志文件副本来保持数据库持续运行。
虽然丢失非关键性文件不会导致数据库崩溃，但它会削弱数据库的功能。
例如：
• 丢失索引表空间会导致应用程序和查询的运行速度大幅减慢，或者，如果这些索引用于强制实施约束，则丢失后甚至会导致应用程序无法使用。
• 只要丢失的联机重做日志组不是当前的联机日志组，就可能会导致数据库操作挂起（当LGWR 下次尝试写入组时），直到生成新的日志文件为止。
• 丢失临时表空间会使用户无法运行查询或创建索引，直到将这些用户分配到新的临时表空间为止。
- 自动恢复临时文件
如果缺失任何一个临时文件，则需要临时空间来执行的SQL 语句会失败。
SQL> select * from big_table order by
1,2,3,4,5,6,7,8,9,10,11,12,13;
select * from big_table order by
1,2,3,4,5,6,7,8,9,10,11,12,13
*
ERROR at line 1:
ORA-01565: error in identifying file '/u01/app/oracle/oradata/orcl/temp01.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
好消息：
• 启动时自动重新创建临时文件
• （也可以手动重新创建）
自动恢复临时文件
如果属于临时表空间的某个临时文件(tempfile) 丢失或损坏，则该文件中的区将不可用。
在执行需要临时空间进行排序的SQL 语句期间，此问题会声明自己为错误。
上面显示的SQL 语句有很长一串要作为排序依据的列，因此需要临时空间。
执行需要排序的此语句时会遇到缺失文件错误。
Oracle DB 实例可以在临时文件缺失的情况下启动。
启动数据库实例时如果有任何临时文件不存在，系统都会自动创建这些临时文件，从而使数据库可以正常打开。
发生这种情况时，启动过程中会在预警日志中显示类似下面的消息：
Re-creating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf
如果用户认为手动重新创建能更好地服务（这种情况的可能性不大），可以使用下列命令：
SQL> ALTER TABLESPACE temp ADD TEMPFILE
'/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M;
SQL> ALTER TABLESPACE temp DROP TEMPFILE
'/u01/app/oracle/oradata/orcl/temp01.dbf';
- 日志组状态：综述
在任何给定时间，重做日志组的状态都会是以下值之一：
• CURRENT：LGWR 进程当前正在向该重做日志组写入重做数据。
• ACTIVE：不再向该重做日志组写入数据，但是恢复实例时仍然需要它。
• INACTIVE：不再向该重做日志组写入数据，且恢复实例时也不再需要它。
日志组状态：综述
要处理重做日志文件的丢失问题，了解重做日志组的可能状态非常重要。
在Oracle DB 正常运行过程中，重做日志组会循环经历三种不同的状态。按照循环的顺序，状态分别是：
• CURRENT：此状态表明LGWR 正在向该重做日志组写入数据，以记录数据库中正在进行的所有事务处理的重做数据。该日志组将保持此状态，直到切换至其它日志组为止。
• ACTIVE：该重做日志组仍包含恢复实例所需的重做数据。这是尚未执行检查点时重做日志组所处的状态，检查点会将重做日志组中出现的所有数据更改写出到数据文件。
• INACTIVE：已实际执行了上面讨论的检查点，这意味着恢复实例时不再需要该重做日志组，它可以变为下一个CURRENT日志组。
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关键字来清除日志文件。
这用于用户确认可能存在依赖于该重做日志进行恢复的备份，并且你决定放弃该恢复机会。
这可能是所需要的，尤其是在纠正重做日志组问题后立即执行其它备份，不再需要该重做日志文件时。可能需要使用重做日志才能恢复当前处于脱机状态下的数据文件。
- 丢失了索引表空间后进行恢复
• 可以在不执行RECOVER任务的情况下恢复仅包含索引的表空间。
• 如果属于仅包含索引的表空间的数据文件丢失，则更为简单的方法可能是重新创建表空间和重新创建索引。
丢失了索引表空间后进行恢复
索引是计算所得的对象，因为索引不提供任何原始数据，仅是已存在数据的另一种表示。
因此，在大多数情况下，可以很容易地重新创建索引。如果你的表空间仅包含索引，则可以简化在丢失了属于该表空间的数据文件后的恢复工作。
如果丢失了此类数据文件，则可以执行以下步骤：
1. 删除数据文件。
2. 删除表空间。
3. 重新创建索引表空间。
4. 重新创建包含在表空间中的索引。
- 重新创建索引
使用以下选项可缩短重新创建索引所花费的时间：
• PARALLEL
• NOLOGGING
SQL> CREATE INDEX rname_idx ON hr.regions (region_name) PARALLEL 4;
重新创建索引
创建或重新创建索引时，可以使用以下关键字来缩短创建时间：
• PARALLEL（NOPARALLEL是默认值）：多个进程可以同时协同工作来创建索引。
与单个服务器进程按顺序创建索引相比，通过在多个服务器进程之间分配创建索引所需的工作，Oracle Server 可以更快速地创建索引。将随机对表取样并找到一组索引关键字，这些索引关键字按照指定的并行度将索引平均分为相同数目的片段。
第一组查询进程将扫描表，提取关键字和行的ID 对并基于关键字将每个对发送到第二组查询进程中的一个进程中。
第二组中的每个进程都对关键字进行排序并按常规方式构建索引。
所有索引片段构建完成后，并行协调程序会将这些片段（已进行排序）级联以形成最终的索引。
• NOLOGGING：使用此关键字会加快索引的创建速度，因为创建进程创建的重做日志条目极少。
这种工作量大幅减小的重做生成也适用于直接路径插入和Direct Loader (SQL*Loader) 插入。
这是永久性属性，因此将显示在数据字典中。可以随时使用ALTER INDEX NOLOGGING/LOGGING命令来加以更新。
注：可以覆盖NOLOGGING（如果你在数据库级别或表空间级别使用Data Guard 或FORCE LOGGING）。
索引丢失时，更为快速、简单的方法是重新创建而不是尝试恢复索引。
你可以使用具有CONTENT=METADATA_ONLY参数的数据泵导出实用程序来创建包含重新创建索引的SQL 命令的转储文件。
你也可以针对之前创建的转储文件使用具有SQLFILE=<filename>参数的数据泵导入实用程序。
- 面向数据库管理员的验证方法
面向数据库管理员的验证方法
根据是希望在数据库所在的那一台计算机上本地管理数据库，还是希望从一个远程客户机管理许多不同的数据库服务器，可以选择使用操作系统验证或口令文件验证来验证数据库管理员：
• 如果数据库具有口令文件且你已经具有SYSDBA或SYSOPER系统权限，则可以通过口令文件进行验证。
• 如果服务器未使用口令文件，或者你不具有SYSDBA或SYSOPER权限因而不在口令文件中，则可以使用操作系统验证。
在大多数操作系统中，数据库管理员的验证需要将数据库管理员的操作系统用户名放置到一个特殊组中，一般称为OSDBA。
该组中的用户将被授予SYSDBA权限。一个类似的组OSOPER用于向用户授予SYSOPER权限。
操作系统验证优先于口令文件验证。特别是，如果你是操作系统的OSDBA或OSOPER组的成员，并且以SYSDBA或SYSOPER身份连接，则连接你您将具有相关的管理权限，而与你指定的用户名/口令无关。
- 重新创建口令验证文件
SQL> grant sysdba to admin2;
grant sysdba to admin2
*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled
在丢失了口令文件后进行恢复：
1. 使用orapwd重新创建口令文件。
$ orapwd file=$ORACLE_HOME/dbs/orapworcl password=ora entries=5
2. 向口令文件添加用户并向每个用户分配适当的权限。
重新创建口令验证文件
Oracle DB 提供了一个口令实用程序orapwd来创建口令文件。
使用SYSDBA权限连接时，是以SYS方案连接，而不是以与用户名关联的方案连接。
对于SYSOPER，则将连接到PUBLIC方案。
使用口令文件访问数据库的权限由授权用户发出的GRANT命令提供。
通常，口令文件不包含在备份中，因为几乎在所有情况下，均可方便地重新创建口令文件。
保护口令文件以及标识口令文件位置的环境变量对于系统安全性是至关重要的。
对这些文件和环境变量具有访问权限的任何用户都可能潜在地影响连接的安全性。
如果使用REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE或SHARED装载了数据库或实例，则不应删除或修改口令文件。否则，将无法使用该口令文件从远程重新连接。
注：口令区分大小写，在重新创建口令文件时必须考虑到这一点。而且，如果通过IGNORECASE=Y 选项创建了原始口令文件，则必须使用相同的选项重新创建口令文件。
使用口令文件
下面是重新创建口令文件的步骤：
1. 使用口令实用程序orapwd创建口令文件。
orapwd file=filename password=password entries=max_users
其中：
- filename是口令文件的名称（必需）。
- password是SYS的口令（可选）。如果未包括password参数，则会提示你输入口令。
- entries是允许以SYSDBA或SYSOPER身份连接的不同用户的最大数量。如果超出了此数值，必须创建新口令文件。使用较大的数值比较保险。“等号”(=) 字符两边没有空格。
示例：orapwd file=$ORACLE_HOME/dbs/orapwU15 password=admin entries=5
2. 使用在步骤1 中创建的口令文件连接到数据库，并根据需要授予权限。
SQL> CONNECT sys/admin AS SYSDBA
SQL> grant sysdba to admin2;
口令文件位置
UNIX：$ORACLE_HOME/dbs
Windows：%ORACLE_HOME%database
维护口令文件
使用操作系统命令删除现有口令文件，然后使用口令实用程序创建新口令文件。
- 比较完全恢复和不完全恢复
恢复有两类作用域：
• 完全恢复：将数据库恢复到当前最新状态，包括直至请求恢复时进行的所有已提交的数据更改
• 不完全或时间点恢复：将数据库恢复到请求恢复操作之前指定的过去时间点
比较完全恢复和不完全恢复
执行完全恢复时，数据库会完全恢复到最新状态，包括到当前为止提交的所有数据修改。
但是执行不完全恢复时，数据库会恢复到过去时间点的某个点。它还被称为“数据库时间点恢复”。
这意味着会缺失一些事务处理；即恢复目标时间和当前时间之间所做的所有数据修改都会丢失。
在很多情况下，这正是想要的结果，因为可能需要撤消对数据库进行的一些更改。恢复到过去的某一时间点是删除误更改的一种方法。
- 完全恢复过程
完全恢复过程
下面的步骤说明了执行完全恢复期间要采取的操作：
1. 通过备份还原损坏或缺失的文件。
2. 根据需要应用增量备份、归档重做日志文件和联机重做日志文件中的更改。将重做日志更改应用于数据文件，直到到达当前联机日志，并且重新输入了最新的事务处理。在整个过程中会生成还原块。这称为前滚或高速缓存恢复。
3. 此时，还原的数据文件中包含已提交和未提交的更改。
4. 还原块用于回退任何未提交的更改。有时也称为事务处理恢复。
5. 此时，数据文件处于已恢复状态，且与数据库中的其它数据文件一致。
- 时间点恢复过程
时间点恢复过程
不完全恢复或数据库时间点恢复使用备份来生成非当前版本的数据库。也就是说，不会应用最新备份之后生成的所有重做记录。仅当绝对必要时才执行此类恢复。要执行时间点恢复，你需要：
• 恢复点之前生成的所有数据文件的有效脱机或联机备份
• 从备份时间到指定恢复时间的所有归档日志
下面列出了执行时间点恢复的过程：
1. 从备份还原数据文件：如果还原点目标并不很新，则使用的备份可能也不是最新的。这需要使用OS 命令或RMAN RESTORE命令来复制文件。
2. 使用RECOVER命令：从归档重做日志文件应用重做，根据需要包括尽可能多的数据以达到还原点目标。
3. 恢复以后的状态：此时，数据文件包含一些已提交的事务处理和未提交的事务处理，因为重做可以包含未提交的数据。
4. 使用ALTER DATABASE OPEN命令：应用还原之前数据库已打开。这是为了提供更高的可用性。
5. 应用还原数据：应用重做时，同时会应用支持还原数据文件的重做。这样，还原可以应用于数据文件，以便还原任何未提交的事务处理。这是接下来要完成的操作。
6. 过程完成：此时，数据文件已恢复到所选择的时间点。
如果必须执行恢复且发现包含事务处理的归档日志丢失，其中的事务处理是在还原所用的备份的创建时间与目标恢复SCN 之间发生的，则时间点恢复是唯一的选择。没有丢失的日志，则没有该期间内对数据文件进行更新的记录。唯一的选择就是从还原备份的时间点恢复数据库，直到未损坏的归档日志系列所允许的时间点，然后使用RESETLOGS选项打开数据库。缺失的重做日志文件中的或之后的所有更改都将丢失。
- 恢复只读表空间
对于只读表空间，在进行用户管理的备份和恢复时需要注意以下特殊事项：
• 不必为了创建数据文件的副本而将其置于备份模式。
• 创建表空间或数据文件的副本之前，不必使其脱机。
恢复只读表空间
由于不会向只读表空间写入数据，因此要考虑一些可使恢复过程更快更有效的特殊注意事项。
将只读表空间复制到备份位置之前，不必将其置于备份模式或使其脱机。只需复制只读表空间。
还原只读表空间时，需要使该表空间脱机、还原属于该表空间的数据文件，然后使该表空间重新联机。
请考虑下面这种将只读表空间更改为读/写状态的情况：
1. 创建只读表空间的备份。
2. 将该表空间置于读写状态。
3. 恢复该表空间。
在步骤1 中创建的备份仍可用于恢复此表空间，即使自执行备份以来，表空间已被置于读写状态且可能已在其中写入数据。在这种情况下，从这类备份还原文件后，需要恢复表空间。
- 恢复NOLOGGING数据库对象
QL> CREATE TABLE sales_copy NOLOGGING;
SQL> INSERT /*+ APPEND */ INTO sales_copy
2 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选项。