ora-600 [4000]的又一次处理

今天公司有台开发库由于大楼停电，导致数据库起不来，报出的错误是ora-600 [4000] [5]这样的错误。类似于这样的错误我以前也处理过一次。详见这里。

由于是开发库又有备份，所以把这个案例拿来玩玩：

[@more@]

用10046事件打开，可以看到下面的信息：

create table bootstrap$ ( line# number not null, obj# number not null, sql_text varchar2(4000) not null)

storage (initial 50K objno 56 extents (file 1 block 377))

PARSING IN CURSOR #2 len=55 dep=1 uid=0 oct=3 lid=0 tim=1220697932880067 hv=2111436465 ad='64bde9f4'

select line#, sql_text from bootstrap$ where obj# != :1

END OF STMT

PARSE #2:c=1000,e=481,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1220697932880063

BINDS #2:

kkscoacd

Bind#0

oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00

oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0

kxsbbbfp=b7107aa4 bln=22 avl=02 flg=05

value=56

EXEC #2:c=1000,e=921,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1220697932881080

WAIT #2: nam='db file sequential read' ela= 27 file#=1 block#=377 blocks=1 obj#=-1 tim=1220697932881195

*** 2009-08-11 20:44:43.270

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [4000], [5], [], [], [], [], [], []

Current SQL statement for this session:

select line#, sql_text from bootstrap$ where obj# != :1

从这里看来，是访问bootstrap$基表中的obj#=-1时报出了这个错误。

从这里看有点奇怪的是bootstrap$这样的基本的回滚信息应该是在system回滚段中，为什么会出现5号回滚段中呢(ora-600 [4000]的第一个参数)？

准备用bbed(先配置listfile)查看一下，从前面的信息可以看出bootstrap$基表的段头块号为377号块，那么数据块是在378号。

[oracle@aepdb_dev3@aepdb]./bbed listfile=/tmp/1.lst

BBED> set block 378

BLOCK# 378

BBED> show all;

FILE# 1

BLOCK# 378

OFFSET 0

DBA 0x0040017a (4194682 1,378)

FILENAME /opt/oracle/oradata/aepdb/system01.dbf

BIFILE bifile.bbd

LISTFILE /tmp/1.lst

BLOCKSIZE 8192

MODE Browse

EDIT Unrecoverable

IBASE Dec

OBASE Dec

WIDTH 80

COUNT 512

LOGFILE log.bbd

SPOOL No

BBED> dump

File: /opt/oracle/oradata/aepdb/system01.dbf (1)

Block: 378 Offsets: 0 to 511 Dba:0x0040017a

------------------------------------------------------------------------

06a20000 7a014000 5e010000 00000106 d9130000 01000000 38000000 c8000000

00000000 01000200 00000000 00002200 02000000 82014000 02000c00 18200000

5e010000 00011800 ffff4200 c8048604 86040000 1800a31f 1a1f951d cd1c4e1b

7a1aad19 49177b16 b315d614 0a14ef12 05120e11 380f680e 910d790c 69099c08

5e068e05 c8040000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

通过与正常的数据库比较，发现00002200 02000000 82014000 02000c00这个是ITL的信息中的XID和UBA。1820是ITL中的lck和Flag。

从中可以看出378号块上的ITL指向的回滚段的确是0号回滚段，即system回滚段，它的事务状态为- - U-，而锁住的行数为18（16进制，十进制为24）。

如果真的是读这个块报出ORA－600号错误的话， 那么600号错误的第一个参数不匹配。说明应该不是这个块引起的。

在这过程中，我也偿试着修改了这个事务的信息，将1820改为0080，即事务状态改为C- - -，锁信息清掉，这时用verify检查块时，会报这个块会被一个不存在事务给锁住了。

找了一个正常关闭的数据库(同一个版本的)，通过bbed查看378号，发现这些信息都是一样的。通过bbed将正常的378号块copy过来，启动数据库，报一样的错误。所以从侧面证明了不是378号这个块引起的错误。

这里有个疑点就是为什么这里会报出ora-600 [4000] [5]这样的信息呢？光看Trace文件的前面部分是无法解释这个问题的。

于是继续查看10046的trace文件，发现这样一段信息：

BH (0x46fb4e80) file#: 1 rdba: 0x00400179 (1/377) class: 4 ba: 0x463e6000

set: 10 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 0

dbwrid: 0 obj: 56 objn: 56 tsn: 0 afn: 1

hash: [46ff9b54,6733ed0c] lru: [673b6998,673b6998]

ckptq: [NULL] fileq: [NULL] objq: [65d83ecc,65d83ecc]

st: XCURRENT md: NULL tch: 1

flags:

LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

buffer tsn: 0 rdba: 0x00400179 (1/377)

scn: 0x058a.ecbf9baa seq: 0x01 flg: 0x04 tail: 0x9baa1001

frmt: 0x02 chkval: 0xb2d9 type: 0x10=DATA SEGMENT HEADER - UNLIMITED

Extent Control Header

-----------------------------------------------------------------

Extent Header:: spare1: 0 spare2: 0 #extents: 1 #blocks: 7

last map 0x00000000 #maps: 0 offset: 4128

Highwater:: 0x0040017d ext#: 0 blk#: 3 ext size: 7

#blocks in seg. hdr's freelists: 1

#blocks below: 3

mapblk 0x00000000 offset: 0

Disk Lock:: Locked by xid: 0x0005.02d.0002bcf4

Map Header:: next 0x00000000 #extents: 1 obj#: 56 flag: 0x40000000

Extent Map

也就是说在377号块上面有一个disk lock，它的事务指向的正是5号回滚段。那么原因非常可能就是这个引起的。

用bbed查找了一个377号块，

BBED> find /x f4bc

File: /opt/oracle/oradata/aepdb/system01.dbf (1)

Block: 377 Offsets: 84 to 595 Dba:0x00400179

------------------------------------------------------------------------

f4bc0200 01000000 01000000 00000000 38000000 00000040 7a014000 07000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

现在整个块中就只有这么一处有这样的信息，为了看的更清楚：

BBED> set offset 70

OFFSET 70

BBED> dump

File: /opt/oracle/oradata/aepdb/system01.dbf (1)

Block: 377 Offsets: 70 to 581 Dba:0x00400179

------------------------------------------------------------------------

00000100 00000300 00000500 2d00f4bc 02000100 00000100 00000000 00003800

00000000 00407a01 40000700 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

正好与trace文件中相匹配。

查看正常的数据库（相同版本）的377号块，是没有这个信息的。那就说明是377号这个块出现了问题。

采用bbed将正常的377号块copy过来，启动数据库，一切正常！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/100091/viewspace-1025195/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/100091/viewspace-1025195/