Data Recovery Advisor（以下简称DRA）是Oracle的一个内置（Build-In）工具，用于进行数据错误、损坏的报告和修复建议。比如，DRA能够自动发现当前存在坏块，并且查看备份资料库（RMAN），给出修复建议和语句。DRA甚至可以做到“一键式”的恢复，敲一个修复命令，就自动执行修复脚本，将错误解除。
DRA是和Oracle经典备份还原工具RMAN绑定使用的。DRA是自动在后台进行数据库状态检查和数据收集，一旦发现错误，就会自动的进行修复建议的提示。DRA目前可以在两种方式下进行工作，一个是数据库启动障碍，比如启动过程报错。另一个是运行过程障碍，例如运行中数据库异常损坏（如数据文件被后台删除）。
目前DRA可以支持User界面和命令行两种方式工作。在OEM中，我们点击修复链接，查看或者直接解决问题。在命令行中，我们可以使用RMAN的命令进行处理。
下面就两种方式进行分别的测试，测试之前需要对数据库进行备份。
1.准备工作
确定为archive log模式：
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 3
Next log sequence to archive 5
Current log sequence 5
通过rman进行全备：
RMAN> backup database plus archivelog delete input;
2.测试示启动过程中的数据库故障
目前数据库有2个controlfile
SQL> select name from v$controlfile;
NAME
--------------------------------------------------------------------------------
/u01/oradata/orcl/control01.ctl
/u01/app/oracle/fast_recovery_area/orcl/control02.ctl
现在模拟数据库异常中断后一个控制文件丢失：
SQL> shutdown abort;
ORACLE instance shut down.
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@qht131 ~]$ cd /u01/oradata/orcl/
[oracle@qht131 orcl]$ mv control01.ctl control01.ctl_bak
[oracle@qht131 orcl]$ ll
total 2887504
-rw-r----- 1 oracle oinstall 9748480 Jul 19 17:01 control01.ctl_bak
再次启动数据库时，必然会报错：
SQL> startup
ORACLE instance started.
Total System Global Area 313159680 bytes
Fixed Size 2227944 bytes
Variable Size 205521176 bytes
Database Buffers 100663296 bytes
Redo Buffers 4747264 bytes
ORA-00205: error in identifying control file, check alert log for more infoalert.log报错如下：
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/oradata/orcl/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: ALTER DATABASE MOUNT...
Checker run found 1 new persistent data failures
在进入mount阶段的时候，Oracle发现control file不能读取的问题。注意alert log片段的最后一行，Oracle说：我引入的checker不断在进行轮询过程，发现这个问题还存在。这个时候，熟练的DBA是可以继续工作的，或者用备份进行恢复，或者拷贝一个完全版本。但是在DRA时代，我们还可以“问问Oracle Advisor怎么办？”。
此时，我们使用rman，来查看信息。
RMAN>list failure;
using target database control file instead of recovery catalog
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
162 CRITICAL OPEN 19-JUL-18 Control file /u01/oradata/orcl/control01.ctl is missing
信息非常详细，Oracle给这个错误一个编号，并且分了级别，有了说明信息。明确说明问题在哪儿。
List failure命令是将所有的错误失败显示出来，我们还可以针对一个failure id进行信息显示。
RMAN> list failure 162 detail;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
162 CRITICAL OPEN 19-JUL-18 Control file /u01/oradata/orcl/control01.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
---------- -------- --------- ------------- -------
162 CRITICAL OPEN 19-JUL-18 Control file /u01/oradata/orcl/control01.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/orcl/control01.ctl
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2452854497.hm
Oracle DRA说，我们可以使用Control File的另一个冗余拷贝进行恢复。并且给出了一个repair script。
[oracle@qht131 orcl]$ cat /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2452854497.hm
# restore control file using multiplexed copy
restore controlfile from '/u01/app/oracle/fast_recovery_area/orcl/control02.ctl';
sql 'alter database mount';
两条语句，都是要求在rman下面运行。一个是使用当前镜像文件进行恢复，另一个是启动数据库。
我们听从DRA的指令，手工运行一下脚本命令。此时，数据库处在一个中间启动状态。
SQL> select status from v$instance;
STATUS
------------
STARTED
RMAN> restore controlfile from '/u01/app/oracle/fast_recovery_area/orcl/control02.ctl';
Starting restore at 19-JUL-18
using target database control file instead of recovery catalog
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/orcl/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/orcl/control02.ctl
Finished restore at 19-JUL-18
RMAN> sql 'alter database mount';
sql statement: alter database mount
released channel: ORA_DISK_1
RMAN> list failure;
no failures found that match specification
此时，数据库可以顺利的open，并且原来的list failure错误信息消失。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> alter database open;
Database altered.
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@qht131 orcl]$ ll
total 2897040
-rw-r----- 1 oracle oinstall 9748480 Jul 19 17:17 control01.ctl
-rw-r----- 1 oracle oinstall 9748480 Jul 19 17:01 control01.ctl_bak
根据DRA的建议，控制文件已恢复出来，数据库正常启动。
3.测试数据库运行中发生故障
Undo表空间是Oracle核心表空间之一，删除之后会引起比较严重的问题故障。
SQL> select file_name from dba_data_files where tablespace_name='UNDOTBS1';
FILE_NAME
--------------------------------------------------------------------------------
/u01/oradata/orcl/undotbs01.dbf
当前数据库处在Open运行状态，突然Undo文件被后OS层面删除。
[oracle@qht131 orcl]$ mv /u01/oradata/orcl/undotbs01.dbf /u01/oradata/orcl/undotbs01.dbf.bak
[oracle@qht131 orcl]$ ls -l | grep undo
-rw-r----- 1 oracle oinstall 985669632 Jul 20 08:23 undotbs01.dbf.bak
alert log日志报错：
2018-07-20 08:25:31.701000 +08:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_24772.trc:
ORA-12012: error on auto execute of job 4002
ORA-01116: error in opening database file 3
ORA-01110: data file 3: '/u01/oradata/orcl/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_24772.trc:
ORA-12012: error on auto execute of job 3
ORA-01116: error in opening database file 3
ORA-01110: data file 3: '/u01/oradata/orcl/undotbs01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
此时，我们在rman上使用list failure命令，查看生成的错误信息。
RMAN> list failure;
using target database control file instead of recovery catalog
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
245 HIGH OPEN 19-JUL-18 One or more non-system datafiles are missing
我们使用advisor failure，查看一个Oracle的建议。
RMAN> advise failure ;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
245 HIGH OPEN 19-JUL-18 One or more non-system datafiles are missing
analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=43 device type=DISK
analyzing automatic repair options complete
Mandatory Manual Actions
========================
1. If file /u01/oradata/orcl/undotbs01.dbf was unintentionally renamed or moved, restore it
2. Automatic repairs may be available if you shutdown the database and restart it in mount mode
3. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair
Optional Manual Actions
=======================
no manual actions available
Automated Repair Options
========================
no automatic repair options available
注意，在automated repair options中，我们没有看到脚本信息。说明Oracle好像在目前也没有太好的方法。在Manual Actions中，Oracle DRA要求将数据库重启到mount状态，才能有自动脚本的出现。Manual Actions是那些Oracle觉得需要用户手工执行才能继续下去的步骤。
重新启动一下库，加载到mount状态。
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 313159680 bytes
Fixed Size 2227944 bytes
Variable Size 205521176 bytes
Database Buffers 100663296 bytes
Redo Buffers 4747264 bytes
Database mounted.
此时再次使用DRA工具，看问题和提示内容。
RMAN> advise failure;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
245 HIGH OPEN 19-JUL-18 One or more non-system datafiles are missing
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
=======================
1. If file /u01/oradata/orcl/undotbs01.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover datafile 3
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2259266757.hm
查看一下建议的脚本：
[oracle@qht131 orcl]$ cat /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_2259266757.hm
# restore and recover datafile
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
在上篇中，我们是手工打开hm文件，看里面的脚本。其实还可以使用repair failure review命令来查看执行语句。
RMAN> repair failure preview;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_4003389433.hm
contents of repair script:
# restore and recover datafile
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
注意：此时Oracle DRA发现了当前我们有Undo的备份和归档日志。所以使用restore之后伴随recover，可以快速实现恢复。
如果在preview中没有发现什么问题，可以repair failure命令执行进行恢复。
RMAN> repair failure;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/orcl/orcl/hm/reco_4003389433.hm
contents of repair script:
# restore and recover datafile
restore datafile 3;
recover datafile 3;
sql 'alter database datafile 3 online';
Do you really want to execute the above repair (enter YES or NO)? yes
executing repair script
Starting restore at 20-JUL-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00003 to /u01/oradata/orcl/undotbs01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/ORCL/backupset/2018_07_19/o1_mf_nnndf_TAG20180719T165553_fo0njtcw_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/ORCL/backupset/2018_07_19/o1_mf_nnndf_TAG20180719T165553_fo0njtcw_.bkp tag=TAG20180719T165553
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 20-JUL-18
Starting recover at 20-JUL-18
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 20-JUL-18
sql statement: alter database datafile 3 online
repair failure complete
Do you want to open the database (enter YES or NO)? yes
database opened
此时，数据库错误消除，数据库被正确打开。
最后，我们还有一个命令可以使用，就是change failure。Change Failure命令的作用就是显示的将错误的状态修改掉。最常用的做法是：当一个错误发生的时候，如果我们没有在RMAN层面上去解决，比如使用冷备份方法还原。Failure信息是不会变化状态的。此时，可以使用change failure命令将状态设置为Closed，命令如：change failure all closed。
注意，目前的11g版本中，Data Recovery Advisor还不支持RAC环境。
随着版本的推进，越来越多的Advisor出现在我们周围。从目前看，Advisor只是一个信息咨询专家库，我们可以听也可以不听。很多老资格的DBA对这些“花哨”产品也是比较不屑。笔者认为大可不必。
工具的出现，自动化、智能化是任何一个事物的必然过程。可能在早期的版本中，一些Advisor存在这样或者那样的问题。但是随着不断的改进升级，这些Advisor变的越来越智能，也是不可辩驳的事实。最终智能化也只是时间的问题了。
那么，作为传统业务的DBA我们自己，应该怎么做呢？首先，原理一定要作为基础。任何技术，特别是Oracle近几个版本，都遵循9i时期奠定的基础框架和机制。很多花哨产品都是以此为基础进行研发，所以理解基础很重要。其次，业务价值。开发DBA是一个体现业务价值的重要方面，将数据库的理念带入到架构设计、开发过程，可以让我们的系统衔接的更平顺。最后就是行业优势，Oracle是死的，应用行业是多样的。每一个行业都有自己的特点和取向。作为DBA，特别是资深DBA，对业务数据的敏感度要远大于开发团队的很多人，把价值发挥出来，空间自然不会小。