数据库管理员的职责包括：

? 尽量避免数据库出现故障

? 延长平均故障间隔时间(MTBF)

? 通过冗余方式保护关键组件

? 缩短平均恢复时间(MTTR)

? 最大程度地减少数据丢失

数据库管理员(DBA) 的目标是确保数据库处于打开状态，以供用户在需要时使用。要实现这个目标，DBA 应完成以下工作（与系统管理员合作）：

? 预计导致出现故障的常见原因并努力避免出现这些原因

? 尽量延长平均故障间隔时间(MTBF)，否则会对可用性产生负面影响

? 尽量确保硬件可靠，通过冗余方式保护关键组件，并定期执行操作系统维护。Oracle DB 提供了用于提高MTBF 的高级配置选件，其中包括：

- Real Application Cluster

-Streams

- Oracle Data Guard

? 提前确定恢复过程方案并配置备份，以便在需要时随时使用，从而缩短平均恢复时间(MTTR)

? 最大程度地减少数据丢失。负责履行接受的最佳实践的DBA 可配置数据库，以便提交的事务处理永不丢失。用于保证实现此目标的具体项包括：

- 归档日志文件

- 闪回技术

- 备用数据库和Oracle Data Guard

故障通常可分为以下几类：

? 语句失败

? 用户进程失败

? 网络故障

? 用户错误

? 实例故障

? 介质故障

故障类别

? 语句失败：单个数据库操作（选择、插入、更新或删除）失败。

? 用户进程失败：单个数据库会话失败。

? 网络故障：与数据库的连接断开。

? 用户错误：用户成功完成了操作，但是操作不正确（删除了表，或输入了错误数据）。

单个数据库操作失败后，可能需要DBA 进行干预，才能纠正用户权限或数据库空间分配错误。即使对于未直接发生在工作范围内的问题，也可能需要DBA 进行协助来诊断故障。这可能会因组织而异。例如，对于使用现成应用程序的组织（即没有软件开发人员的组织），DBA 是唯一的联系点，必须由其检查应用程序中的逻辑错误。

要了解应用程序中的逻辑错误，应该与开发人员合作来了解问题的范围。Oracle DB 工具可以帮助检查审计线索或之前的事务处理，从而提供帮助。

注：在许多情况下，语句失败是由设计决定的，且是想要的结果。例如，安全策略和限额规则通常是提前制定的。用户尝试超越他或她的限制而产生错误时，操作失败可能正是想要的结果，而不需要任何解决方案。

与实例异常断开的用户进程中可能包含正在进行的、需要回退的未提交任务。为了确保服务器进程会话仍保持连接，进程监视器(PMON) 后台进程会定期轮询服务器进程。如果PMON发现某个服务器进程的用户不再处于连接状态，PMON会从任何正在进行的事务处理中进行恢复；还会回退未提交的更改并解除失败会话持有的任何锁。

从用户进程失败中进行恢复时不需要DBA 进行干预，但是管理员必须观察变化趋势。有一个或两个用户异常断开时不必担心。有时可能会出现用户进程少量失败的情况。但持续发生相同的失败和系统性失败表示存在其它的问题。如果异常断开连接比例较高，则可能表示用户需要培训（包括学习如何注销程序，而不是仅仅终止程序）。此外，还可能表示存在网络或应用程序问题。

网络故障的最佳解决方法是为网络连接提供冗余路径。通过备份监听程序、网络连接和网络接口卡可降低出现网络故障的机率，从而避免影响系统可用性。

用户可能会无意中删除或修改了数据。如果尚未提交或退出其程序，则只需回退即可。

可通过Enterprise Manager 或SQL 接口使用Oracle LogMiner来查询联机重做日志和归档重做日志。事务处理数据保留在联机重做日志中的时间可能比保留在还原段中的时间长，如果配置了对重做信息进行归档，则在删除归档文件之前会一直保留重做信息。

通过将表闪回到删除前的状态，用户删除表后可从回收站中恢复表。如果清除了回收站，或者用户使用PURGE选项删除了表，那么在数据库配置正确的情况下，仍然可通过使用时间点恢复(PITR) 来恢复删除的表。

使用闪回技术：

? 查看数据的以前状态

? 来回读取数据

? 协助用户执行错误分析和恢复

闪回技术

Oracle DB 提供了Oracle 闪回技术：该技术由一组功能组成，支持查看数据的以前状态和来回读取数据，而无需从备份还原数据库。使用此技术可帮助用户分析错误并从错误中进行恢复。如果用户提交了错误的更改，可使用以下功能分析错误：

? 闪回查询：查看在过去某个时间点存在的已提交数据。带有AS OF子句的SELECT命令通过时间戳或SCN 引用过去的某一时间。

? 闪回版本查询：查看在特定时间间隔内提交的历史数据。使用SELECT命令的VERSIONS BETWEEN子句（出于性能方面的考虑，使用了现有索引）。

? 闪回事务处理查询：查看在事务处理级进行的所有数据库更改。

 

从用户错误中进行恢复的可能的解决方法包括：

? 闪回事务处理恢复：回退特定的事务处理及其从属事务处理。

? 闪回表：将一个或多个表读回到其以前某一时间的内容，而不影响其它数据库对象。

? 闪回删除：通过将已删除的表及其从属对象（如索引和触发器）从回收站返回到数据库，撤消删除该表的操作。

? 闪回数据库：将数据库返回到某个过去时间或系统更改号(SCN)。

如果在同步所有数据库文件之前关闭了数据库实例，就会发生实例故障。出现软硬件故障，或者使用SHUTDOWN ABORT和STARTUP FORCE紧急关闭命令时，也会发生实例故障。如果启用了Oracle Restart 并且它在监视数据库，则从实例故障中恢复很少需要管理员进行操作。数据库实例一发生故障，Oracle Restart 就会尝试重新启动该实例。如果需要手动干预，则可能存在较严重的问题，阻止该实例重新启动，例如内存CPU 故障。

 

要了解实例恢复，需要了解特定后台进程的功能。

每隔三秒（或更加频繁），CKPT 进程就会在控制文件中存储一次数据，以记录DBWn已将哪些修改的数据块从SGA 写到磁盘。这称为“增量检查点”。检查点的用途是标识联机重做日志文件开始进行实例恢复的位置（这个位置称为“检查点位置”）。如果发生日志切换，则CKPT 进程还会将此检查点信息写入数据文件头。

存在检查点是由于下列原因：

? 确保内存中已修改的数据块能够定期写入到磁盘，这样在系统或数据库出现故障时就不会丢失数据

? 减少实例恢复所需的时间（只需要处理上一个检查点之后的联机重做日志文件条目，即可进行恢复。）

? 确保所有已提交的数据在关闭期间会被写入数据文件

CKPT 进程写入的检查点信息包括检查点位置、系统更改编号(SCN)、联机重做日志文件中恢复开始的位置、有关日志的信息等等。

注：CKPT 进程不会将数据块写入磁盘或将重做数据块写入联机重做日志文件。

了解实例恢复：重做日志文件和日志写进程

重做日志文件记录了由于事务处理和Oracle 服务器内部操作而对数据库所做的更改。（事务处理是逻辑工作单元，由用户运行的一个或多个SQL 语句组成。）重做日志文件会保护数据库，避免因断电、磁盘故障等引起的系统故障导致数据不完整。重做日志文件应该多路复用，才能确保在出现磁盘故障事件时不丢失其中存储的信息。

重做日志由重做日志文件组组成，而重做日志文件组由重做日志文件及其多路复用的副本组成。每个相同的副本均称作该组的一个成员，每个组按数字标识。日志写进程(LGWR)将重做记录从重做日志缓冲区写入重做日志组的所有成员，直至填满文件或请求日志切换操作。

然后，切换至下一组文件并执行写入操作。将以循环方式使用重做日志组。

最佳实践提示：如果可能，多路复用的重做日志文件应驻留在不同的磁盘上。

自动实例恢复或崩溃恢复：

? 原因是尝试打开的数据库中的文件在关闭时不同步

? 使用重做日志组中存储的信息来同步文件

? 涉及到两个不同的操作：

实例恢复

Oracle DB 会自动从实例故障中进行恢复。实例所需要做的就是正常启动。如果Oracle Restart 已启用并且配置为监视该数据库，则该启动操作会自动进行。实例会装载控制文件，然后尝试打开数据文件。如果实例发现数据文件在关闭期间尚未同步，则会使用重做日志组中包含的信息将数据文件前滚到关闭时的状态。然后，将打开数据库，并回退所有未提交的事务处理。

实例恢复的阶段

要使实例打开一个数据文件，数据文件头中包含的系统更改号(SCN) 必须与数据库控制文件中存储的当前SCN 匹配。

如果编号不匹配，实例会应用联机重做日志中的重做数据，并按顺序“重做”事务处理，直到数据文件处于最新状态。所有数据文件都与控制文件同步后，就会打开数据库，此时用户可以进行登录。

应用重做日志后，会应用所有事务处理，使数据库返回到出现错误时的状态。这通常包括正在进行但尚未提交的事务处理。打开数据库之后，会回退那些未提交的事务处理。在实例恢复的回退阶段结束时，数据文件只包含已提交的数据。

? 在实例恢复期间，必须将检查点位置与重做日志末尾之间的事务处理应用到数据文件。

? 通过控制检查点位置与重做日志末尾之间的差异可优化实例恢复。

优化实例恢复

在实例对事务处理返回commit complete之前，在重做日志组中会记录事务处理信息。

重做日志组中的信息可确保在出现错误时可恢复事务处理。另外，事务处理信息还需要写入数据文件。由于数据文件写进程比重做写进程要慢很多，因此，通常在重做日志组中记录了信息之后，才会执行数据文件写操作。（数据文件随机写进程比重做日志文件连续写进程要慢。）

每隔三秒，检查点进程就会在控制文件中记录关于重做日志中检查点位置的信息。因此，Oracle DB 认为此时间点之前记录的所有重做日志项对数据库恢复来说都是不需要的。在图形中，带条纹的块尚未写入磁盘。

实例恢复所需的时间指的是将数据文件的最后一个检查点推进到控制文件中记录的最新SCN 所需的时间。管理员通过设置MTTR 目标（以秒为单位）以及调整重做日志组的大小来控制该时间。例如，对于两个重做组，检查点位置与重做日志组末尾之间的距离不能大于最小重做日志组的90%。

? 以秒或分钟为单位指定所需的时间。

使用MTTR 指导

选择以下选项之一可对您设置MTTR 目标有所帮助：

? Enterprise Manager > Advisor Central > MTTR Advisor（Enterprise Manager > 指导中心> MTTR 指导），其中“Advisor Central（指导中心）”位于“Related Links（相关链接）”部分中

? Enterprise Manager > Availability > Recovery Settings（Enterprise Manager > 可用性> 恢复设置）

FAST_START_MTTR_TARGET初始化参数可以简化实例或系统故障的恢复时间配置。

MTTR 指导可将FAST_START_MTTR_TARGET值转换为多个参数，以便在所需时间内（或者在尽量接近此时间的范围内）启用实例恢复。请注意，将

FAST_START_MTTR_TARGET参数显式设置为0会禁用MTTR 指导。

FAST_START_MTTR_TARGET参数的设置值必须支持系统的服务级协议。如果MTTR 目标的值较小，则会因增加了数据文件写入次数而增加I/O 开销（这会影响性能）。但是，如果MTTR 目标设置得过大，则实例在崩溃后需要花费较长的时间才会恢复。

Oracle Corporation 将介质故障定义为导致一个或多个数据库文件（数据文件、控制文件或重做日志文件）丢失或损坏的任何故障。

要从介质故障中进行恢复，需要还原并恢复缺失的文件。为确保可从介质故障中恢复数据库。

要配置数据库的最大可恢复性，必须执行以下操作：

? 计划常规备份

? 多路复用控制文件

? 多路复用重做日志组

? 保留重做日志的归档副本

配置可恢复性

要为数据提供最大的保护，必须：

? 计划常规备份

修复介质故障时通常需要从备份中还原丢失或损坏的文件。

? 多路复用控制文件

与数据库关联的所有控制文件都是相同的。如果丢失一个控制文件，则并不难恢复；但如果丢失了所有控制文件，则很难恢复。为了避免丢失所有控制文件，至少要有两个副本。

? 多路复用重做日志组

要从实例故障或介质故障中进行恢复，可使用重做日志信息将数据文件前滚到上次提交的事务处理。如果重做日志组依赖于一个重做日志文件，那么丢失这个文件意味着很可能会丢失数据。至少要确保每个重做日志组有两个副本；如果可能的话，每个副本都应在不同的磁盘控制器中。

? 保留重做日志的归档副本

如果丢失了某个文件并从备份中进行了还原，则实例必须应用重做信息，以便将该文件推进到控制文件中包含的最新SCN。使用默认设置时，重做信息写入数据文件

后，数据库会覆盖这些信息。数据库可配置为在重做日志的归档副本中保留重做信息。这称为将数据库置于ARCHIVELOG模式下。

可以在Enterprise Manager 中或使用命令行执行配置任务。

快速恢复区：

? 强烈建议使用，可简化备份存储管理

? 使用存储空间（与工作数据库文件分开）

? 位置由DB_RECOVERY_FILE_DEST参数指定

? 大小由DB_RECOVERY_FILE_DEST_SIZE参数指定

? 足够大，可存放备份、归档日志、闪回日志、多路复用控制文件和多路复用重做日志

? 根据保留策略自动进行管理

配置快速恢复区意味着确定了位置、大小和保留策略。

配置快速恢复区

快速恢复区是磁盘上为包含归档日志、备份、闪回日志、多路复用控制文件和多路复用重做日志而专门留出的空间。快速恢复区可简化备份存储管理，因此强烈建议使用该功能。

放置快速恢复区的存储位置应该与数据库的数据文件以及主要联机日志文件和控制文件的位置不同。

分配给快速恢复区的磁盘空间量取决于数据库的大小和活动级别。通常情况下，快速恢复区越大，就越有用。理想情况下，快速恢复区应足够大，可存放数据文件和控制文件副本，以及基于保留策略从保留的备份恢复数据库所需的闪回日志、联机重做日志和归档日志。

（简而言之，快速恢复区至少应为数据库大小的两倍，以便可保留一个备份和若干归档日志。）

快速恢复区的空间管理由备份保留策略控制。保留策略确定文件何时过时，即何时这些文件对达到数据恢复目标已不再有用。Oracle DB 通过删除不再需要的文件自动管理该存储。

为了防范数据库故障，数据库控制文件应保存多个副本。

重做日志文件

重做日志组由一个或多个重做日志文件组成。组中的每个日志文件都是相同的。Oracle Corporation 建议每个重做日志组至少包含两个文件。如果使用文件系统存储，则每个成员应该分布在单独的磁盘或控制器上，这样在单个设备出现故障时就不会破坏整个日志组。如果使用ASM 存储，则每个成员应该位于单独的磁盘组中，例如+DATA 和+FRA。

丢失了整个当前日志组是一种最严重的介质故障，因为这会导致数据丢失。但丢失了包括多个成员的日志组中的一个成员是微不足道的，这并不会影响数据库操作（只会导致在预警日志中发布预警）。请记住，由于不能在事务处理信息写入日志之前完成提交，因此多路复用重做日志可能会严重影响到数据库的性能。必须将重做日志文件置于速度最快的控制器服务的速度最快的磁盘中。请尽量不要将其它任何数据库文件与重做日志文件保存在同一磁盘上（除非使用自动存储管理[ASM]）。由于在给定时间只能写入一个组，因此，同一磁盘中包含多个组的成员不会有什么性能影响。

通过在现有日志组中添加成员可多路复用重做日志。要在重做日志组中添加成员（数据库已打开，且不影响用户性能），请执行以下步骤：

1. 选择“Enterprise Manager > Server > Redo Log Groups（Enterprise Manager > 服务器> 重做日志组）”。

2. 选择一个组并单击“Edit（编辑）”按钮，或者单击组编号链接。此时会出现“Edit Redo Log Group（编辑重做日志组）”页。

3. 在“Redo Log Members（重做日志成员）”区域中，单击“Add（添加）”。此时会显示“Add Redo Log Member（添加重做日志成员）”页。

4. 选择适当的“Storage Type（存储类型）”并输入必需的信息。

对于ASM，选择磁盘组，如果需要，指定模板和别名信息。对于“File System（文件系统）”存储，输入文件名和文件目录。单击“Continue（继续）”。针对要多路复用的每个现有组重复以上步骤。

下面显示了将一个重做日志成员添加到重做日志组1（使用ASM）的SQL 语法示例：

SQL> ALTER DATABASE ADD LOGFILE MEMBER ‘+DATA‘ TO GROUP 1;

要保留重做信息，请通过执行以下步骤，创建重做日志文件的归档副本。

1. 指定归档日志文件命名惯例。

2. 指定一个或多个归档日志文件的位置。

3. 将数据库切换为ARCHIVELOG模式。

归档日志文件

实例会将联机重做日志组视为一个可在其中存储事务处理信息的循环缓冲区，因而会填充一个组，然后转到下一个组。写入所有组后，实例开始覆盖第一个日志组中的信息。要对数据库进行配置，以使其具有最大可恢复性，必须指示数据库在允许覆盖重做信息之前生成联机重做日志组的副本。这些副本称为“归档日志”。

要简化归档日志文件的创建过程，请执行以下操作：

1. 指定归档日志的命名惯例。

2. 指定用于存储归档日志的一个或多个目标位置。其中一个目标位置可以是快速恢复区。

3. 将数据库置于ARCHIVELOG模式。

注：如果使用了快速恢复区，则无需执行步骤1 和2。

将数据库置于ARCHIVELOG模式之前，该目标位置应该已存在。如果将某个目录指定为一个目标位置，目录名的末尾应加上斜杠。

ARCn是可选的后台进程。但是，该进程对于在磁盘损坏后恢复数据库非常重要。联机重做日志组填满后，Oracle 实例将开始对下一个联机重做日志组进行写入。从一个联机重做日志组切换到另一个联机重做日志组的过程称为“日志切换”。ARCn进程在每次日志切换时都会对已填满的日志组启动归档。该进程先自动归档联机重做日志组，然后再重用该日志组，从而保留对数据库所做的所有更改。这样即使磁盘驱动器损坏，也可以将数据库 复到故障点。

DBA 必须做出的一个重要决策是将数据库配置为在ARCHIVELOG模式下运行还是将其配置为在NOARCHIVELOG模式下运行。

? 在NOARCHIVELOG模式下，每次进行日志切换时都会覆盖联机重做日志文件。

? 在ARCHIVELOG模式下，必须先归档不活动的已填满联机重做日志文件组，然后才能再次使用这些联机重做日志文件。

附注

? ARCHIVELOG模式对大多数备份策略而言是必不可少的，并且这种模式很容易进行配置。

? 如果归档日志文件目标位置填满或者无法写入，数据库最终将停止。从归档日志文件目标位置删除归档文件，数据库将继续操作。

在“Recovery Settings（恢复设置）”页上指定命名和归档目标位置信息。如果使用文件系统存储，则建议添加不同磁盘中的多个位置。

归档日志文件：命名与目标位置

要配置归档日志文件名和目标位置，请选择“Enterprise Manager > Availability > Configure Recovery Settings（Enterprise Manager > 可用性> 配置恢复设置）”。

每个归档日志文件必须有一个唯一名称，这样可避免覆盖较旧的日志文件。

请指定命名格式，如上图所示。为了帮助创建唯一文件名，Oracle Database 11g允许在名称格式中

使用多个通配符：

? %s：包含日志序列号作为文件名的一部分

? %t：包含线程号作为文件名的一部分

? %r：包含重置日志ID 以确保归档日志文件名是唯一的（甚至在使用某些高级恢复技术重置了日志序列号之后也是如此）

? %d：包含数据库ID 作为文件名的一部分

按照最佳实践，格式应该包含%s、%t和%r（如果多个数据库共享同一归档日志目标位置，则还可以包含%d）。

默认情况下，如果启用了快速恢复区，则指定USE_DB_RECOVERY_FILE_DEST作为归档日志文件目标位置。归档日志文件最多可以写入十个不同的目标位置。目标位置可以是本地目标位置（目录），也可以是远程目标位置（备用数据库的Oracle Net 别名）。单击“Add Another Row（添加另一行）”来添加更多目标位置。要更改恢复设置，必须以SYSDBA或SYSOPER的身份建立连接。

注：如果不希望将归档日志文件发送到USE_DB_RECOVERY_FILE_DEST，请删除此位置。

要将数据库置于ARCHIVELOG模式，请在Oracle Enterprise Manager 中执行以下步骤：

1. 选中“ARCHIVELOGMode（ARCHIVELOG模式）”复选框并单击“Apply（应用）”。只有处于MOUNT状态的数据库才能设置为ARCHIVELOG模式。

2. 重新启动数据库（使用SYSDBA权限）。

3. （可选）查看归档状态。

4. 备份数据库。

注：处于ARCHIVELOG模式下的数据库可访问所有备份和恢复选项。

sqlplus / as sysdba

shutdown immediate

startup mount

alter database archivelog;

alter database open;

archive log list

启用ARCHIVELOG模式

1. 在Enterprise Manager 中，选择“Availability > Configure Recovery Settings > ARCHIVELOG Mode（可用性> 配置恢复设置> ARCHIVELOG 模式）”。

等效的SQL 命令为：SQL> ALTER DATABASE ARCHIVELOG;

只有数据库处于MOUNT状态时，才能发出此命令。因此，必须重新启动实例才能完成这最后一步。

2. 在Enterprise Manager 中重新启动数据库时，系统会提示指定操作系统和数据库身份证明。数据库身份证明必须是具有SYSDBA权限的用户的身份证明。

3. 重新启动实例后，对归档进程、日志格式和日志目标位置所做的更改就会生效。在SQL*Plus 中，可使用ARCHIVE LOG LIST命令查看这些信息。

4. 在切换到ARCHIVELOG模式后备份数据库，原因是数据库只能从该模式下执行的最后一次备份中进行恢复。

数据库处于NOARCHIVELOG模式（默认模式）时，只能恢复到最后一次备份时的状态。

在该备份之后执行的所有事务处理都会丢失。

在ARCHIVELOG模式下，可一直恢复到最后一次提交时的状态。大多数生产数据库都在ARCHIVELOG模式下运行。