当前位置: 首页 > Oracle, oracle 10g, oracle 11g > 正文

恢复数据库时遇到数据文件头损坏

恢复RAC数据库到异机单实例时,遇到UNDO表空间数据文件头损坏的情况,在RESTORE完成后,告警日志大量出现以下告警:

Reading datafile '/data/uatdb/ivldb2_undo.dbf' for corruption at rdba: 0x00000001 (file 7, block 1)
Reread (file 7, block 1) found same corrupt data (no logical check)
Hex dump of (file 7, block 1) in trace file /u01/app/oracle/diag/rdbms/ivldb/uatdb/trace/uatdb_ora_5477.trc
Corrupt block relative dba: 0x00000001 (file 7, block 1)
Bad check value found during deleting datafile copy
Data in bad block:
 type: 0 format: 2 rdba: 0x00000001
 last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000001
 check value in block header: 0x0
 computed block checksum: 0xa701

单实例数据库设置的UNDO表空间并不是这个,检查告警日志发现除这个数据文件外,还有几个业务表空间也出现同样告警,RMAN备份本身就是不一致的,起初我认为对恢复不会有什么影响。可是在RECOVER的时候,遇到RMAN-06094错误:

[oracle@SL010A-IVO04 ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jul 15 22:58:28 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: IVLDB (DBID=1357933872, not open)

RMAN> run{
2> sql 'alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"';
set until time  '2015-07-11 23:59:59';
3> 4> recover database until time  '2015-07-11 23:59:59';
5> }

using target database control file instead of recovery catalog
sql statement: alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"

executing command: SET until clause

Starting recover at 15-JUL-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4348 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/15/2015 22:59:55
RMAN-06094: datafile 7 must be restored

要求必须重新RESTORE这个数据文件,而重新RESTORE这个数据文件的时候,告警日志也出现同样的告警,可是对恢复又没有影响。

RMAN> RESTORE DATAFILE 7;

重新还原这个数据文件后,虽然告警日志也出现这个告警,可是可以顺利恢复了。

RMAN> run{
2> sql 'alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"';
3> set until time  '2015-07-11 23:59:59';
4> recover database until time  '2015-07-11 23:59:59';
5> }

using target database control file instead of recovery catalog
sql statement: alter session set nls_date_format= "YYYY-MM-DD HH24:MI:SS"

executing command: SET until clause

Starting recover at 15-JUL-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4348 device type=DISK

starting media recovery

archived log for thread 1 with sequence 2631 is already on disk as file /data/ivldb/arch/1_2631_875510192.dbf
archived log for thread 1 with sequence 2632 is already on disk as file /data/ivldb/arch/1_2632_875510192.dbf
archived log for thread 1 with sequence 2633 is already on disk as file /data/ivldb/arch/1_2633_875510192.dbf
archived log for thread 2 with sequence 2426 is already on disk as file /data/ivldb/arch/2_2426_875510192.dbf
archived log for thread 2 with sequence 2427 is already on disk as file /data/ivldb/arch/2_2427_875510192.dbf
archived log for thread 2 with sequence 2428 is already on disk as file /data/ivldb/arch/2_2428_875510192.dbf
archived log file name=/data/ivldb/arch/1_2631_875510192.dbf thread=1 sequence=2631
archived log file name=/data/ivldb/arch/2_2426_875510192.dbf thread=2 sequence=2426
archived log file name=/data/ivldb/arch/1_2632_875510192.dbf thread=1 sequence=2632
archived log file name=/data/ivldb/arch/2_2427_875510192.dbf thread=2 sequence=2427
archived log file name=/data/ivldb/arch/2_2428_875510192.dbf thread=2 sequence=2428
archived log file name=/data/ivldb/arch/1_2633_875510192.dbf thread=1 sequence=2633
media recovery complete, elapsed time: 00:00:05
Finished recover at 15-JUL-15

告警日志也显示,恢复正常完成。

Wed Jul 15 23:51:55 2015
alter database recover datafile list clear
Completed: alter database recover datafile list clear
alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 , 17 , 18 , 19 , 20
Completed: alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 , 17 , 18 , 19 , 20
alter database recover datafile list
 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 , 35 , 36 , 37 , 38 , 39 , 40
Completed: alter database recover datafile list
 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 , 35 , 36 , 37 , 38 , 39 , 40
alter database recover datafile list
 41 , 42
Completed: alter database recover datafile list
 41 , 42
alter database recover if needed
 start until time 'JUL 11 2015 23:59:59' using backup controlfile
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 24 slaves
ORA-279 signalled during: alter database recover if needed
 start until time 'JUL 11 2015 23:59:59' using backup controlfile
...
alter database recover logfile '/data/ivldb/arch/1_2631_875510192.dbf'
Media Recovery Log /data/ivldb/arch/1_2631_875510192.dbf
ORA-279 signalled during: alter database recover logfile '/data/ivldb/arch/1_2631_875510192.dbf'...
alter database recover logfile '/data/ivldb/arch/2_2426_875510192.dbf'
Media Recovery Log /data/ivldb/arch/2_2426_875510192.dbf
ORA-279 signalled during: alter database recover logfile '/data/ivldb/arch/2_2426_875510192.dbf'...
alter database recover logfile '/data/ivldb/arch/1_2632_875510192.dbf'
Media Recovery Log /data/ivldb/arch/1_2632_875510192.dbf
ORA-279 signalled during: alter database recover logfile '/data/ivldb/arch/1_2632_875510192.dbf'...
alter database recover logfile '/data/ivldb/arch/2_2427_875510192.dbf'
Media Recovery Log /data/ivldb/arch/2_2427_875510192.dbf
ORA-279 signalled during: alter database recover logfile '/data/ivldb/arch/2_2427_875510192.dbf'...
alter database recover logfile '/data/ivldb/arch/2_2428_875510192.dbf'
Media Recovery Log /data/ivldb/arch/2_2428_875510192.dbf
ORA-279 signalled during: alter database recover logfile '/data/ivldb/arch/2_2428_875510192.dbf'...
alter database recover logfile '/data/ivldb/arch/1_2633_875510192.dbf'
Media Recovery Log /data/ivldb/arch/1_2633_875510192.dbf
Wed Jul 15 23:52:01 2015
Incomplete Recovery applied until change 110694388067 time 07/11/2015 23:59:59
Media Recovery Complete (uatdb)
Completed: alter database recover logfile '/data/ivldb/arch/1_2633_875510192.dbf'

这是什么情况?为什么在还原数据文件的时候,数据文件会损坏呢?不懂!

本文固定链接: http://www.dbdream.com.cn/2015/07/%e6%81%a2%e5%a4%8d%e6%95%b0%e6%8d%ae%e5%ba%93%e6%97%b6%e9%81%87%e5%88%b0%e6%95%b0%e6%8d%ae%e6%96%87%e4%bb%b6%e5%a4%b4%e6%8d%9f%e5%9d%8f/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2015年07月15日发表在 Oracle, oracle 10g, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 恢复数据库时遇到数据文件头损坏 | 信春哥,系统稳,闭眼上线不回滚!
关键字: , ,

恢复数据库时遇到数据文件头损坏:目前有1 条留言

  1. 沙发
    嘿嘿:

    给春哥点个赞

    2015-07-16 17:46 [回复]

发表评论

快捷键:Ctrl+Enter