Data Recovery Advisor

考虑下面显示的错误：

SQL> conn scott/tiger
Connected.
SQL> create table t (col1 number);
create table t (col1 number)
*
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/home/oracle/oradata/PRODB3/users01.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

看起来是不是很熟悉？无论您是否做过 DBA，您可能都不止一次看到过该消息。该错误发生的原因是无法获得特定的数据文件 — 该文件可能已经受损，或者可能有人在数据库运行时删除了该文件。在任何情况下，您都需要在问题的影响范围扩大之前采取一些主动措施。

在 Oracle Database 11g 中，新增的 Data Recovery Advisor 极大地简化了该操作。该 Advisor 有两种形式：命令行模式，以及作为 Oracle Enterprise Manager Database Control 的一个屏幕。根据具体的情况，每种形式各有其优点。例如，如果您希望通过 shell 脚本自动识别此类文件并通过 cron 或 at 之类的实用程序计划恢复操作，那么选择前者将很有用。对于希望借助 GUI 来指导他们完成该过程的 DBA 新手来说，后一种方法将更有帮助。下面，我将对这两种形式分别进行描述。

命令行方式
命令行方式通过 RMAN 执行。首先，启动 RMAN 进程并连接到目标。

$ rman target=/

Recovery Manager: Release 11.1.0.5.0 - Beta on Sun Jul 15 19:43:45 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: PRODB3 (DBID=3132722606)

假设发生了某个错误，您希望找出原因。使用 list failure 命令可以立即知道答案。

RMAN> list failure;

如果没有错误，该命令将返回以下消息：

no failures found that match specification

如果有错误，将显示如下更具说明性的消息：

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
----------      --------     ---------     -------------       -------
142        HIGH     OPEN      15-JUL-07     One or more non-system datafiles are missing

该消息表明某些数据文件已丢失。由于这些数据文件属于 SYSTEM 以外的表空间，因此数据库会挂起，并使该表空间脱机。该错误相当严重，因此优先级设为 HIGH。每个故障都有一个故障 ID，以方便各个故障的识别和解决。例如，您可以执行以下命令来了解故障 142 的详细信息。

RMAN> list failure 142 detail;

该命令将向您显示错误的确切原因。

现在，进入了关键部分：如何纠正该错误？经验丰富的 DBA 或许不需要进一步的帮助就可以顺利解决该问题，但是 DBA 新手（甚至包括一些有经验但是知识陈旧的 DBA）希望在这里获得一些指导。他们可以向 Data Recovery Advisor 寻求帮助：

RMAN> advise failure;

以上命令的响应将对错误进行详细的解释，并说明如何纠正该错误：

List of Database Failures
=========================

Failure ID Priority Status    Time Detected Summary
----------      --------     ---------     -------------       -------
142        HIGH     OPEN      15-JUL-07     One or more non-system datafiles are missing

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /home/oracle/oradata/PRODB3/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
------ ------------------
1      Restore and recover datafile 4  
  Strategy: The repair includes complete media recovery with no data loss
  Repair script: /home/oracle/app/diag/rdbms/prodb3/PRODB3/hm/reco_3162589478.hm

该输出有几个重要部分。首先，该 Advisor 对错误进行了分析。在该案例中，错误很明显：数据文件丢失。接下来，Advisor 建议了一个策略。在该案例中，这也是相当简单的：还原和恢复文件。（请注意，我故意选择了一个简单的示例以便将注意力集中到工具的使用上，而不是讨论数据库可能出现故障的各种情况以及如何恢复。动态性能视图 V$IR_MANUAL_CHECKLIST 也显示了该信息。）

然而，Data Recovery Advisor 执行的最有用的任务却显示在最后一行：它将生成一个可用于修复数据文件或解决该问题的脚本。该脚本可以完成所有工作，您连一行代码都不用编写。

有时，Advisor 无法获取它所需的所有信息。例如，在该案例中，它不知道是有人将文件移到了另一个位置，还是对该文件进行了重新命名。在这种情况下，它会建议将文件移回原来的位置，并恢复原来的名称（在 Optional Manual Actions 下）。

现在，脚本已经准备好了。您准备好执行它了吗？我不了解您的情况，但是我会验证该脚本实际上会首先执行什么。因此，我执行以下命令来“预览”修复任务将执行的操作：

RMAN> repair failure preview;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /home/oracle/app/diag/rdbms/prodb3/PRODB3/hm/reco_741461097.hm

contents of repair script:
   # restore and recover datafile
   sql 'alter database datafile 4 offline';
   restore datafile 4;
   recover datafile 4;
   sql 'alter database datafile 4 online';

很好，修复任务似乎在做着和我使用 RMAN 去做的同样的事情。现在，我可以通过发出以下命令来执行实际的修复：

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /home/oracle/app/diag/rdbms/prodb3/PRODB3/hm/reco_3162589478.hm

contents of repair script:
   # restore and recover datafile
   sql 'alter database datafile 4 offline';
   restore datafile 4;
   recover datafile 4;
   sql 'alter database datafile 4 online';

Do you really want to execute the above repair (enter YES or NO)?

假设结果是 OK，我回答 YES，操作将继续执行：

executing repair script

sql statement: alter database datafile 4 offline

Starting restore at 15-JUL-07
using channel ORA_DISK_1

channel ORA_DISK_1: restoring datafile 00004
input datafile copy RECID=5 STAMP=628025835 file name=/home/oracle/flasharea/PRODB3/datafile/o1_mf_users_39ocxbv3_.dbf
destination for restore of datafile 00004: /home/oracle/oradata/PRODB3/users01.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00004
output file name=/home/oracle/oradata/PRODB3/users01.dbf RECID=0 STAMP=0
Finished restore at 15-JUL-07

Starting recover at 15-JUL-07
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 51 is already on disk as file /home/oracle/flasharea/PRODB3/archivelog/2007_07_15/o1_mf_1_51_39ocxxdw_.arc
...  

and so on ...
name=/home/oracle/flasharea/PRODB3/archivelog/2007_07_15/o1_mf_1_55_39ocy9ox_.arc thread=1 sequence=55
media recovery complete, elapsed time: 00:00:01
Finished recover at 15-JUL-07

sql statement: alter database datafile 4 online
repair failure complete

RMAN>

注意，RMAN 在尝试修复之前如何提示您。如果使用脚本，您可能不希望提示；而是希望继续进行并修复，没有任何提示。如果是这样，只需在 RMAN 提示符下使用 repair failure noprompt 即可。