对DBA而言，数据备份、还原是日常工作的基本功。Oracle发展到今天，自动化、智能化是一个重要的发展方向。数据库可以自动的诊断问题故障，并且解决修复错误，可能离我们并不遥远。
数据备份和还原，在Oracle DBA学习过程中，占到了很大的篇幅。从冷备份到热备份，从完全恢复到非完全恢复，这个过程中涉及了很多的技术细节和知识点。一些DBA初始接触这些概念和操作，容易被弄乱。Oracle 11g推出的Data Recovery Advisor，就是提供给我们一个自动诊断、修复数据库的选择。
1、Advisor
从9i和10g开始，我们就开始接触各种的Advisor。从内存大小，例如SGA、Buffer Cache和PGA，到存储段结构Segment Space Advisor和SQL Tuning Advisor，Oracle在试图构建起一个Advisor Framework。
Oracle的Advisor大都是有“后台运行、自动建议”的特点。这些Advisor往往是和Oracle自动后台作业绑定，由一个或者多个后台进程进行自动信息收集诊断，并且最后生成诊断建议。
应该说，Advisor是Oracle迈向自动化、智能化的一个重要战略步骤。本篇介绍的Data Recovery Advisor就是应用于数据恢复领域的一个重要Advisor组件。
Data Recovery Advisor（以下简称DRA）是Oracle的一个内置（Build-In）工具，用于进行数据错误、损坏的报告和修复建议。比如，DRA能够自动发现当前存在坏块，并且查看备份资料库（RMAN），给出修复建议和语句。DRA甚至可以做到“一键式”的恢复，敲一个修复命令，就自动执行修复脚本，将错误解除。
DRA是和Oracle经典备份还原工具RMAN绑定使用的。DRA是自动在后台进行数据库状态检查和数据收集，一旦发现错误，就会自动的进行修复建议的提示。DRA目前可以在两种方式下进行工作，一个是数据库启动障碍，比如启动过程报错。另一个是运行过程障碍，例如运行中数据库异常损坏（如数据文件被后台删除）。
目前DRA可以支持User界面和命令行两种方式工作。在OEM中，我们点击修复链接，查看或者直接解决问题。在命令行中，我们可以使用RMAN的命令进行处理。
2、环境准备
所谓，“巧妇难为无米之炊”。应该注意：DRA是一个自动辅助工具，对DBA而言，是一个规范操作的辅助者，而不是“点石成金”的“万灵药”。DRA进行数据恢复所依据的，也是Oracle原有的备份还原体系，并没有引入什么特殊功能。换句话说，一个非归档、无备份、无冗余配置的数据库，有致命错误发生的时候，DRA也是无能为力的。
这也就是说，备份还是要做。我们首先在实验前，进行一个完整备份。选择Oracle 11g进行实验，开启归档模式。
[oracle@bspdev ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Fri Sep 6 06:09:29 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 849530880 bytes
（篇幅原因，有省略……）
Redo Buffers 5132288 bytes
Database mounted.
--查看是否归档模式
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 172
Next log sequence to archive 174
Current log sequence 174
使用RMAN进行一个全备份。
SQL> alter database open;
Database altered.
[oracle@bspdev ~]$ rman nocatalog
Recovery Manager: Release 11.2.0.1.0 - Production on Fri Sep 6 06:14:28 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> connect target /
connected to target database: WILSON (DBID=3906514064)
using target database control file instead of recovery catalog
RMAN> backup database plus archivelog delete input;
Starting backup at 06-SEP-13
current log archived
（略过细节......）
在RMAN中，我们可以使用list failure all;的DRA命令来查看当前存在的错误列表。
RMAN> list failure all;
no failures found that match specification
下面，我们分别选择启动过程和运行过程两个场景进行恢复演示。
3、启动过程数据库故障演示
在启动过程出现数据库错误占到了数据库错误的相当比例。DRA是可以在这个过程中帮助我们解决问题的。
首先，我们先制造一个问题。当前存在两个控制文件，互为备份。
SQL> col name for a100;
SQL> select name from v$controlfile;
NAME
---------------------------------------------------------------
/u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl
/u01/flash_recovery_area/WILSON/controlfile/o1_mf_7xt44kbv_.ctl
意外中断系统，删除一个控制文件。
SQL> conn / as sysdba
Connected.
SQL> shutdown abort;
ORACLE instance shut down.
[oracle@bspdev ~]$ cd /u01/oradata/WILSON/controlfile/
[oracle@bspdev controlfile]$ ls -l
total 9856
-rw-r----- 1 oracle oinstall 10076160 Sep 6 06:36 o1_mf_7xt44jkr_.ctl
[oracle@bspdev controlfile]$ mv o1_mf_7xt44jkr_.ctl o1_mf_7xt44jkr_.ctl.bak
[oracle@bspdev controlfile]$ ls -l
total 9856
-rw-r----- 1 oracle oinstall 10076160 Sep 6 06:36 o1_mf_7xt44jkr_.ctl.bak
再次启动的时候，数据库必然会有一个报错的动作。
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 849530880 bytes
Fixed Size 1339824 bytes
Variable Size 616566352 bytes
Database Buffers 226492416 bytes
Redo Buffers 5132288 bytes
ORA-00205: error in identifying control file, check alert log for more info
定位控制文件失败，从alert log中找到内容。
MMNL started with pid=16, OS id=4418
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01
Fri Sep 06 07:06:42 2013
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: ALTER DATABASE MOUNT...
Fri Sep 06 07:06:44 2013
Checker run found 1 new persistent data failures
在进入mount阶段的时候，Oracle发现control file不能读取的问题。注意alert log片段的最后一行，Oracle说：我引入的checker不断在进行轮询过程，发现这个问题还存在。这个时候，熟练的DBA是可以继续工作的，或者用备份进行恢复，或者拷贝一个完全版本。但是在DRA时代，我们还可以“问问Oracle Advisor怎么办？”。
此时，我们使用rman，来查看信息。
RMAN> list failure ;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
3842 CRITICAL OPEN 06-SEP-13 Control file /u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl is missing
信息非常详细，Oracle给这个错误一个编号，并且分了级别，有了说明信息。明确说明问题在哪儿。
List failure命令是将所有的错误失败显示出来，我们还可以针对一个failure id进行信息显示。
RMAN> list failure 3842 detail;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
3842 CRITICAL OPEN 06-SEP-13 Control file /u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl is missing
Impact: Database cannot be mounted
List failure是第一个DRA命令。Advise failure是问问Oracle怎么办？
RMAN> advise failure;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
3842 CRITICAL OPEN 06-SEP-13 Control file /u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl is missing
Impact: Database cannot be mounted
analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
no manual actions available
Automated Repair Options
========================
Option Repair Description –可用的修复措施
------ ------------------
1 Use a multiplexed copy to restore control file /u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl
Strategy: The repair includes complete media recovery with no data loss
Repair script. /u01/diag/rdbms/wilson/wilson/hm/reco_148645850.hm
Oracle DRA说，我们可以使用Control File的另一个冗余拷贝进行恢复。并且给出了一个repair script。
[oracle@bspdev controlfile]$ cat cat /u01/diag/rdbms/wilson/wilson/hm/reco_148645850.hm
cat: cat: No such file or directory
# restore control file using multiplexed copy
restore controlfile from '/u01/flash_recovery_area/WILSON/controlfile/o1_mf_7xt44kbv_.ctl';
sql 'alter database mount';
两条语句，都是要求在rman下面运行。一个是使用当前镜像文件进行恢复，另一个是启动数据库。
我们听从DRA的指令，手工运行一下脚本命令。此时，数据库处在一个中间启动状态。
--实例已经启动
[oracle@bspdev controlfile]$ ps -ef | grep pmon
oracle 4360 1 0 07:06 ? 00:00:00 ora_pmon_wilson
oracle 4551 3270 0 07:15 pts/0 00:00:00 grep pmon
SQL> select status from v$instance;
STATUS
------------
STARTED
RMAN中执行程序脚本。
--执行脚本命令
RMAN> restore controlfile from '/u01/flash_recovery_area/WILSON/controlfile/o1_mf_7xt44kbv_.ctl';
Starting restore at 06-SEP-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: copied control file copy
output file name=/u01/oradata/WILSON/controlfile/o1_mf_7xt44jkr_.ctl
output file name=/u01/flash_recovery_area/WILSON/controlfile/o1_mf_7xt44kbv_.ctl
Finished restore at 06-SEP-13
RMAN> sql 'alter database mount';
sql statement: alter database mount
released channel: ORA_DISK_1
此时，数据库可以顺利的open，并且原来的list failure错误信息消失。
--进入open状态
SQL> conn / as sysdba
Connected.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
[oracle@bspdev controlfile]$ ls -l
total 19712
-rw-r----- 1 oracle oinstall 10076160 Sep 6 07:21 o1_mf_7xt44jkr_.ctl
-rw-r----- 1 oracle oinstall 10076160 Sep 6 06:36 o1_mf_7xt44jkr_.ctl.bak
RMAN> list failure all;
no failures found that match specification
这个案例告诉我们，RMAN中的DRA可以做到在启动过程中，不断诊断发现问题，提供解决方案。更重要的是还可以提供状态修改的脚本语句。
下面，我们进行一个Open状态故障的诊断，并且看看怎么在DRA如何实现“一键式”系统修复。
