oracle 跳过offline,Oracle11g数据库数据文件意外offline的处理过程

给客户做数据库巡检时，数据库告警日志发现如下错误提示：

Mon Aug 01 15:57:39 2016

Errors in file /u01/app/oracle/diag/rdbms/sjjhdb/sjjhdb1/trace/sjjhdb1_m000_31546.trc:

ORA-01135: file 43 accessed for DML/query is offline

ORA-01110: data file 43: '+DATA/dt_gspopulation08.dbf'

从错误信息可以明显的看到，43

号数据文件处于脱机状态，而数据库中的

DML/query

操作一直在试图访问该文件，从这里可以明确的知道，该文件是意外脱机，并且该文件里存储的数据是业务需要的数据。我们通过检查来验证一下

43

号数据文件的状态：

SQL> select file#,name , status from v$datafile;

FILE# NAME

STATUS

---------- ------------------------------------------------------------------------------------------ -------

34 +DATA/dt_center05.dbf

ONLINE

35 +DATA/dt_center06.dbf

ONLINE

36 +DATA/dt_gspopulation01.dbf

ONLINE

37 +DATA/dt_gspopulation02.dbf

ONLINE

38 +DATA/dt_gspopulation03.dbf

ONLINE

39 +DATA/dt_gspopulation04.dbf

ONLINE

40 +DATA/dt_gspopulation05.dbf

ONLINE

41 +DATA/dt_gspopulation06.dbf

ONLINE

42 +DATA/dt_gspopulation07.dbf

ONLINE

43 +DATA/dt_gspopulation08.dbf

RECOVER

44 +DATA/dt_gspopulation008.dbf

ONLINE

49 rows selected.

(部分结果省略了)

查看43

号文件头部

scn

号：

SQL> select file#,status,checkpoint_change# from v$datafile_header;

FILE# STATUS  CHECKPOINT_CHANGE#

---------- ------- ------------------

34 ONLINE

8153080523

35 ONLINE

8153080523

36 ONLINE

8153080523

37 ONLINE

8153080523

38 ONLINE

8153080523

39 ONLINE

8153080523

40 ONLINE

8153080523

41 ONLINE

8153080523

42 ONLINE

8153080523

43 OFFLINE

8063759520

44 ONLINE

8153080523

49 rows selected.

(部分结果省略了)

可以非常清楚的看到，43

号数据文件处于脱机状态且需要介质恢复，头部

scn

号比其他数据文件差距一个数量级。

遇到这种情况第一步肯定是视图将43

号文件联机，当然，肯定会提示需要介质恢复：

SQL>alter database datafile 43 online;

第 1

行出现错误

:

ORA-01113: file 43 media recovery

ORA-01110: datafile 43: '+DATA/dt_gspopulation08.dbf'

SQL> recover datafile 43;

ORA-00279: change 8063759520 generated at 07/27/2016 16:27:18 needed for thread 2

ORA-00289: suggestion : +DATA

ORA-00280: change 8063759520 for thread 2 is in sequence #8909

Specify log: {=suggested | filename | AUTO | CANCEL}

auto

ORA-00308: cannot open archived log '+DATA'

ORA-17503: ksfdopn:2 Failed to open file +DATA

ORA-15045: ASM file name '+DATA' is not in reference form

ORA-00308: cannot open archived log '+DATA'

ORA-17503: ksfdopn:2 Failed to open file +DATA

ORA-15045: ASM file name '+DATA' is not in reference form

介质恢复出现问题，不能打开‘

+DATA

’

指定目录下的归档日志文件，需要07/27/2016 16:27:18

这个时间点的

2

号线程的

8909

号日志文件，从时间看，这已经是

4

天前了，如果没有对归档日志做备份，那么这只能通过修改数据文件头

scn

号进行不完全恢复，将数据文件联机。非常幸运的是该库是在归档模式下运行的且归档日志备份存量是一周。所以这个恢复起来就相对比较简单，但是要扫描

5

天的备份集，会花费一会儿时间。

RMAN> recover datafile 43;

省略部分输出信息。。。

channel default: deleting archived log(s)

archived log file name=+DATA/sjjhdb/archivelog/2016_08_01/thread_2_seq_9310.576.918758139 RECID=16760 STAMP=918758148

channel ORA_DISK_1: starting archived log restore to default destination

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=6697

channel ORA_DISK_1: reading from backup piece /backup/sjjh_bak/rmanbackup/hdrc4tt0_1_1

channel ORA_DISK_1: piece handle=/backup/sjjh_bak/rmanbackup/hdrc4tt0_1_1 tag=ARC_TAG20160801T040530

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

channel default: deleting archived log(s)

archived log file name=+DATA/sjjhdb/archivelog/2016_08_01/thread_1_seq_6697.576.918758155 RECID=16761 STAMP=918758164

Finished recover at 01-AUG-16

RMAN>

看到Finished recover at 01-AUG-16

可以确定介质恢复已经完成，接着就是将

43

号文件联机：

SQL> alter database datafile 43 online;

Database altered.

SQL>

检查联机后的43

号文件信息：

SQL> select file#,status,checkpoint_change# from v$datafile_header;

FILE# STATUS  CHECKPOINT_CHANGE#

---------- ------- ------------------

23 ONLINE

8157837655

24 ONLINE

8157837655

25 ONLINE

8157837655

26 ONLINE

8157837655

27 ONLINE

8157837655

28 ONLINE

8157837655

29 ONLINE

8157837655

30 ONLINE

8157837655

31 ONLINE

8157837655

32 ONLINE

8157837655

33 ONLINE

8157837655

FILE# STATUS  CHECKPOINT_CHANGE#

---------- ------- ------------------

34 ONLINE

8157837655

35 ONLINE

8157837655

36 ONLINE

8157837655

37 ONLINE

8157837655

38 ONLINE

8157837655

39 ONLINE

8157837655

40 ONLINE

8157837655

41 ONLINE

8157837655

42 ONLINE

8157837655

43 ONLINE

8159145457

44 ONLINE

8157837655

49 rows selected.

SQL>

可以看到43

号数据文件的头部

scn

号已经比其他文件高出一部分，这个不用担心，正常的，因为在日志恢复的时候，部分操作相当于通过提前已经写入到

43

号文件中，导致

43

号文件头部

scn

号超前，但是过一段时间，所有数据文件的头部

scn

都会一致的。接着检查数据文件状态：

SQL> select file#,name,status from v$datafile;

FILE# NAME

STATUS

---------- ------------------------------------------------------------------------------------------ -------

34 +DATA/dt_center05.dbf

ONLINE

35 +DATA/dt_center06.dbf

ONLINE

36 +DATA/dt_gspopulation01.dbf

ONLINE

37 +DATA/dt_gspopulation02.dbf

ONLINE

38 +DATA/dt_gspopulation03.dbf

ONLINE

39 +DATA/dt_gspopulation04.dbf

ONLINE

40 +DATA/dt_gspopulation05.dbf

ONLINE

41 +DATA/dt_gspopulation06.dbf

ONLINE

42 +DATA/dt_gspopulation07.dbf

ONLINE

43 +DATA/dt_gspopulation08.dbf

ONLINE

44 +DATA/dt_gspopulation008.dbf

ONLINE

49 rows selected.

可以看到，43

号文件状态已经为

online

状态。数据库告警日志也不再报出先前的错误信息。