前在线日志文件损坏与ora-600 [4000]处理

logzgh

这次又是一台机器上面有两个实例A和B。又是由于非当前的在线日志文件的状态是处于closed状态的(裸设备)，于是dba将A节点的非当前在线日志文件填加到了B节点上面去了，于是在A节点日志发生切换时，导致了当前在线日志文件损坏。

一般情况下当前在线日志文件损坏也是还好处理的，但是这次却是较为复杂。。。。

系统环境：aix p550，oracle 9206




首先检查v$datafile_header，发现checkpoint_change#都是一致的。

于是按着一般的当前在线日志文件损坏步骤处理：

增加下列参数至Oracle启动文件:

_allow_resetlogs_corruption=TRUE

_corrupted_rollback_segments=(list of all your rollback segments)
注释掉启动文件中的rollback_segments参数或undo_tablespaces参数
startup mount
recover database until cancel
alter database open resetlogs;

一般情况下，open resetlogs后最容易出现的600号错误为ora-600 [2662]和ora-600 [2256]。这两个错误也相对来说好处理一些，只需要采用10015事件adjust scn号即可。

但是这次我却是碰到了ora-600 [4000]号错误。

Errors in file /home/oracle/app/oracle/admin/test/udump/test_ora_2838638.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Mon Aug 14 15:05:31 2006
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 2838638

metalink上对该错误的解释是：

DESCRIPTION:

This has the potential to be a very serious error.

It means that Oracle has tried to find an undo segment number in the
dictionary cache and failed.

ARGUMENTS:
Arg [a] Undo segment number

FUNCTIONALITY:
KERNEL TRANSACTION UNDO

IMPACT:
INSTANCE FAILURE - Instance will not restart
STATEMENT FAILURE

由于一开始_corrupted_rollback_segments里面只是列到_syssmu20$，于是将它列到_syssmu60$。重试后还是报这个错。

增加10513事件，禁止smon进程回滚，结果还是一样。

在600号的Trace文件中有：

ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1

于是我怀疑会不会是undo$基表中没有46号回滚段的信息？

采用bbed检查undo$表格，发现里面是有这个回滚段的信息。

于是我想这个错误是出现在访问obj$基表上面，也就是说该表格的scn号与系统当前的scn号是不一致的。于是我想偿试修改该块的scn号。依然采用bbed，偿试修改该块的scn号。修改后，结果还是一样的。

于是我想应该是obj$基表上还有一个未提交的事务。于是继续查看trace文件，发现如下信息：

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x002e.025.00005b2c 0x00800f78.080c.01 --U- 1 fsc 0x0000.c5b527cf

data_block_dump,data header at 0x700000001f6e044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x700000001f6e044
bdba: 0x0040007a
76543210
flag=--------

很明显，是有一个未提交的事务，于是我就偿试用bbed修改该事务的状态，将该事务改成提交状态。

首先找到itl信息:find /x 00005b2c，找到flag状态，现在其状态是20，也就是未提交，将之修改为80(提交状态)，并修改checkval。

之后去掉所有隐含参数，正常启动数据库，发现后台报出了ora-600[2662]错误。哈哈，事情至此就好办了，采用10015 adjust scn号，正常启动数据库：

Mon Aug 14 15:47:23 2006
Completed: ALTER DATABASE OPEN
Mon Aug 14 15:47:23 2006
Fatal internal error happened while SMON was doing active transaction recovery.
Mon Aug 14 15:47:23 2006
Errors in file /home/oracle/app/oracle/admin/test/bdump/test_smon_2293872.trc:
ORA-00600: internal error code, arguments: [ktpridestroy2], [], [], [], [], [], [], []
SMON: terminating instance due to error 600
Instance terminated by SMON, pid = 2293872

从这块日志可以看出数据库正常启动后，马上因为smon回滚又导致了实例宕下来。

增加10513事件，启动数据库，一切正常。

想drop tablespce undotbs1，但是报出59号回滚段还有active事务无法删除。

于是增加_corrupted_rollback_segments参数，将数据库启来，新建一个回滚表空间，将原来的回滚表空间重建后，一切正常。

leetaedong

最初由 logzgh 发布
[B]Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x002e.025.00005b2c 0x00800f78.080c.01 --U- 1 fsc 0x0000.c5b527cf

data_block_dump,data header at 0x700000001f6e044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x700000001f6e044
bdba: 0x0040007a
76543210
flag=--------

很明显，是有一个未提交的事务 [/B]

赞一个 ，有个问题要问一下：
lz，你是从哪里得出有一个未提交的事务的？
itl 的flag、lock吗？还是要到transaction table slot中看。

因为fast commit cleanout的时候，产生的flag，lock标志和这 是一样的。

d.c.b.a

牛, 这也能搞出来. 实在太......了

Fenng

晕, 原来是你啊,

biti_rainy

这种错误也能出…… 该dba也太不谨慎了！

Fenng

很快就同事了

empo007

学习

oracledba

为什么说10513是禁止smon做事务恢复的？？

wzsh-Sun

前面看的还比较顺，但下面有点看不懂了，总觉得有点怪怪的，楼主有没有看一下那个对应的事务到底是做了什么东西？

NinGoo

这个，也太强了吧，直接改file。。。

10513事件不熟，找时间看看