岁月有声。。。

同一个世界,同一个梦想

ORA-10567,ORA-00313
 

今天碰到一个奇怪的问题,有一个测试的数据库down了,我们一个同事去重新启动一下DB,但是过了几分钟后又down了,察看alert_*.log发现有下列错误:

Errors in file /home/sfcs/admin/world/udump/water_ora_15814.trc:
ORA-00600: internal error code, arguments: [3020], [377610042], [1], [979], [285
], [144], [], []
ORA-10567: Redo is inconsistent with data block (file# 90, block# 122682)
ORA-10564: tablespace IA
ORA-01110: data file 90: '/oradata/100_test/IA09.dbf'
Errors with log .

 

在trc文件中一大堆的dump信息,大概是因为redo中的变更信息和数据文件某一个块的变更信息不一致造成的,baidu了一下,发现这种问题引起的原因很多,但没有给出解法,引起的原因摘录如下:

1.数据库异常关闭,比如断电,shutdown abort等。

2.standbyDB上案例比较多,比如设置standby_file_nanagement=auto,然后primary DB产生新的数据文件时,standby也会产生一份,但产生后standby上有时候会发生这种错误,不知道这种情况算不算BUG。

3.数据库在线数据文件被copy走了,恢复时有可能出现这种问题。

 

当然了,最简单的办法就是使用下面这个SQL,查询出这个块属于哪个segment,如果是index,那恭喜你,数据不会丢失,你可以将此drop掉,然后重新建立一个,如果是数据segment,并且没有作备份,像我们这个测试数据库,那不好意思,看你的运气了。

查询block属于哪个segment的SQL:

SELECT segment_name,segment_type,extent_id,block_id, blocks
from dba_extents t
where
file_id = 29
AND 2819 between block_id and (block_id + blocks - 1)

以下是我们的做法,不一定适合所有情况。

 1.startup mount,使用recover database指令恢复,等完毕后打开一下,如果运气好的话,数据库就打开了。但是在recover的时候报错ORA-00313: open failed for members of log group 4 of thread 1。然后使用不完全恢复指令,输入archive的时候将redo挨个试了一下,到那个需要的日志时报ORA-10567错误,数据库还是打不开。

2.重建了control file文件,继续尝试使用不完全指令恢复,报错

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/data1/sfcs_100/orcl/datafile/system01.dbf'

使用下列SQL发现数据库的所有文件头的checkpoint_change#是一致的

select min(checkpoint_change#)-max(checkpoint_change#) from v$datafile_header

继续恢复时提示需要archive log,察看alert*.log,发现错误: 

Datafile 187: '/oradata/100_test/test_01.dbf'
Media Recovery Log
ORA-279 signalled during: ALTER DATABASE RECOVER  database using backup cont...
Fri Sep 14 15:34:03 2007
ALTER DATABASE RECOVER    CONTINUE DEFAULT
Media Recovery Log /home/sfcs/dbs/arch/1_979.dbf

然后将该文件offline drop,又提示另外一个文件需要恢复。

3.修改spfile中的参数,加上允许redolog坏的参数,并且把undo_managerment设成manual,如下:

undo_management='Manual'
_allow_resetlogs_corruption=true

屏蔽了这一行:
undo_tablespace='UNDOTBS1'

修改undo的目的是为了防止undo的段名和原来数据库的不一致导致恢复错误。

重启数据库到mount状态继续恢复,提示需要archive_log 1_1.dbf,然后就把redo文件输进去,这次居然出现了下面的提示:

Log applied.
Media recovery complete.

看来有戏,果真,open database resetlogs后,数据库居然开启了。

4.收尾的动作:

将修改的spfile恢复成原来的,shutdown数据库,startup一切正常了,整个恢复动作结束。

阅读更多
个人分类: OracleDB
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

ORA-10567,ORA-00313

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭