关闭

ORA-10567,ORA-00313

标签: 数据库databasearchivefilesqlthread
3067人阅读 评论(0) 收藏 举报
分类:
 

今天碰到一个奇怪的问题,有一个测试的数据库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一切正常了,整个恢复动作结束。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:268671次
    • 积分:3844
    • 等级:
    • 排名:第8267名
    • 原创:113篇
    • 转载:16篇
    • 译文:0篇
    • 评论:34条
    最新评论