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過來，啟動資料庫，一切正常！