考虑下面显示的错误:
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 即可。