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

最新推荐文章于 2025-12-05 12:37:18 发布

转载最新推荐文章于 2025-12-05 12:37:18 发布 · 175 阅读

文章标签：

#数据库

本文记录了一次处理ORA-600[4000]错误的过程，通过使用10046事件和BBED工具定位到具体问题所在的数据块，并最终修复了错误。

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

今天公司有台开发库由于大楼停电，导致数据库起不来，报出的错误是ora-600 [4000] [5]这

样的错误。类似于这样的错误我以前也处理过一次。详见这里。

由于是开发库又有备份，所以把这个案例拿来玩玩：
用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 ct=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 ff=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/25136010/viewspace-683008/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25136010/viewspace-683008/