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一切正常了，整个恢复动作结束。