ora-600 4000恢复一例

原文链接 个人博客 http://www.killdb.com/?p=225

下午一个同事遇到经典的ora-600 4000错误，我远程帮忙处理了一下，关于该错误的处理，
网上已经有不少的例子了，通常情况下，该错误通过反复重启数据库，然后可以进行规避
4000错误，但是如果反复重启N次后，错误依旧的话，那么我们只能使用极端手段了。
网上能找到的例子基本上都是一个思路，通过trace 定位到含未提交视图的block，
然后用bbed(windows可以使用UE代替)修改flag，将20修改为80即可，如下：
*** 2011-08-30 15:57:10.037
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4000], [5], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+27 call ksedst1() 0 ? 1 ?
ksedmp()+557 call ksedst() 0 ? 9BF6BA9C ? 0 ? 2A ?
955B3FF0 ? 70000 ?
ksfdmp()+19 call ksedmp() 3 ? BFA3EF80 ? AC152B0 ?
CBD2D20 ? 3 ? CB84398 ?
kgeriv()+188 call 00000000 CBD2D20 ? 3 ?
kgeasi()+113 call kgeriv() CBD2D20 ? B7F50020 ? FA0 ?
1 ? BFA3EFBC ?
ktudba()+264 call kgeasi() CBD2D20 ? B7F50020 ? FA0 ?
2 ? 1 ? 0 ? 5 ? 0 ?
ktrgcm()+6207 call ktudba() 5 ? BFA3F49C ? 0 ? 0 ?
ktrgtc()+941 call ktrgcm() B7F6A3A0 ? 0 ? B7F9EC60 ?
8EF1A0B4 ? 8EF10CE8 ? 198 ?
kdsgrp()+107 call ktrgtc() B7F6A3A0 ? B7F6A348 ?
9C22152 ? BFA3F5B8 ? 240 ?
9C24DD4 ? 9C21D8C ?
kdsfbrcb()+513 call kdsgrp() B7F6A39C ? 0 ? B7F6A39C ?
qertbFetchByRowID() call kdsfbrcb() B7F6A39C ? B7F9EBF8 ? 0 ? 1 ?
+2052 0 ? 0 ?
opifch2()+5157 call 00000000 8EF10A8C ? A11CDF4 ?
BFA3FBE4 ? 1 ?
opifch()+56 call opifch2() 89 ? 5 ? BFA3FE54 ?
opiodr()+2347 call 00000000 5 ? 2 ? BFA40BD0 ?
rpidrus()+434 call opiodr() 5 ? 2 ? BFA40BD0 ? 5 ?
skgmstack()+210 call 00000000 BFA4062C ? CBD2E1C ?
CBD2E1C ? BFA40610 ?
BFA40B14 ? BFA4062C ?
rpidru()+98 call skgmstack() BFA40610 ? CBD2AE0 ? F618 ?
9749536 ? BFA4062C ?
rpiswu2()+1061 call 00000000 BFA40B14 ? BFA40C60 ? 2 ? 2 ?
BFA40AD8 ? 5953 ?
rpidrv()+1915 call rpiswu2() 99C70654 ? 0 ? BFA40AD8 ? 2 ?
BFA40B50 ? 0 ? BFA40AD8 ? 0 ?
97497F0 ? 97498CC ?
BFA40B14 ? 8 ?
rpifch()+56 call rpidrv() 5 ? 5 ? BFA40BD0 ? 8 ?
kqdpts()+174 call rpifch() 5 ? 5 ? 5 ? 3 ? 9AB69FDB ?
7 ?
kqrlfc()+534 call kqdpts() 9AB69E4C ? BFA40E10 ? 35953 ?
CBD2E1C ? CBD2D20 ? 8 ?
kqlbplc()+107 call kqrlfc() 0 ? BFA40DF8 ? 4 ? 0 ?
C251F20 ? 47 ?
kqlblfc()+477 call kqlbplc() 0 ? BFA42734 ? 9CCC2088 ?
CBD2E1C ? CBD2D20 ? 7 ?
adbdrv()+5689 call kqlblfc() 0 ? BFA45508 ?
opiexe()+18301 call adbdrv() 23288 ? 0 ? 18E19E2E ?
48FAE ? 9AB70BC4 ? 0 ?
opiosq0()+3918 call opiexe() 4 ? 0 ? BFA46978 ?
kpooprx()+250 call opiosq0() 3 ? E ? BFA46B80 ? A4 ?
kpoal8()+867 call kpooprx() BFA48D58 ? BFA478F0 ? 1D ?
1 ? 0 ? A4 ?
opiodr()+2347 call 00000000 5E ? 17 ? BFA48D54 ?
ttcpip()+4227 call 00000000 5E ? 17 ? BFA48D54 ? 0 ?
CD51D86 ? 11 ?
opitsk()+1991 call ttcpip() CBDA520 ? 5E ? BFA48D54 ? 0 ?
BFA48234 ? BFA48E78 ?
opiino()+1387 call opitsk() 0 ? 0 ?
opiodr()+2347 call 00000000 3C ? 4 ? BFA49940 ?
opidrv()+915 call opiodr() 3C ? 4 ? BFA49940 ? 0 ?
sou2o()+113 call opidrv() 3C ? 4 ? BFA49940 ?
opimai_real()+212 call sou2o() BFA49924 ? 3C ? 4 ?
BFA49940 ?
main()+111 call opimai_real() 2 ? BFA49970 ?
__libc_start_main() call 00000000 2 ? BFA49A34 ? BFA49A40 ?
+220 4FFAC2 ? 0 ? 12D798 ?

从上面错误来看，我们知道问题出在访问obj#上，下面继续看trace。
Object id on Block? Y
seg/obj: 0x12 csc: 0xb2c.3a7f4d34 itc: 1 flg: - typ: 1 - DATA
 fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.01e.000099e3 0x00802689.29dd.09 --U- 1 fsc 0x0000.3a7f4d35

data_block_dump,data header at 0x847ce044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x847ce044
bdba: 0x0040007a
 76543210
flag=--------
ntab=1
nrow=108
frre=-1
fsbo=0xea
fseo=0x385
avsp=0x369
tosp=0x369
0xe:pti[0] nrow=108 offs=0
上面的信息比较关键，关于XID,UBA的解释，我以前也写过相关文章，这里不多说。
通过bdba: 0x0040007a 我们可以通过如下查询，得知为file 1 block 122.
select dbms_utility.data_block_address_file(TO_NUMBER('40007a', 'XXXXXXXX')) file_id,
dbms_utility.data_block_address_block(TO_NUMBER('40007a', 'XXXXXXXX')) block_id from dual;
编译BBED后，然后看了这个block的ktbbh，如下：BBED> set file 1 block 122
 FILE# 1
 BLOCK# 122BBED> p ktbbh
struct ktbbh, 48 bytes @20
 ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
 union ktbbhsid, 4 bytes @24
 ub4 ktbbhsg1 @24 0x00000012
 ub4 ktbbhod1 @24 0x00000012
 struct ktbbhcsc, 8 bytes @28
 ub4 kscnbas @28 0x3a7f4d34
 ub2 kscnwrp @32 0x0b2c
 b2 ktbbhict @36 1
 ub1 ktbbhflg @38 0x02 (NONE)
 ub1 ktbbhfsl @39 0x00
 ub4 ktbbhfnx @40 0x00000000
 struct ktbbhitl[0], 24 bytes @44
 struct ktbitxid, 8 bytes @44
 ub2 kxidusn @44 0x0005
 ub2 kxidslt @46 0x001e
 ub4 kxidsqn @48 0x000099e3
 struct ktbituba, 8 bytes @52
 ub4 kubadba @52 0x00802689
 ub2 kubaseq @56 0x29dd
 ub1 kubarec @58 0x09
 ub2 ktbitflg @60 0x2001 (KTBFUPB)
 union _ktbitun, 2 bytes @62
 b2 _ktbitfsc @62 0
 ub2 _ktbitwrp @62 0x0000
 ub4 ktbitbas @64 0x3a7f4d35
BBED>

上面的ktbitxid 即为XID的，ktbituba即为UBA，其他的不多说。
这里主要是要修改 ktbitflg，该结构其实占据了2个offset。
修改的时候需要注意一下的是要看os是32位还是64位，32位的话，其字节序是反的。
我这里就直接执行modify /x 8001 offset 60 然后sum apply即可。
然后再重启数据库 直接open，发现不再出现4000错误了，而是2663,这个好办，
该错误跟2662 类似，直接调整scn即可，如下：
alter session set events '10015 trace name adjust_scn level n'; --mount下

最后再次open，错误号即变成了4194，这个就太熟悉不过了，清理undo就行了。
在dbsnake的博客里面，他以前模拟了一下ora-00600 4000错误，详见如下链接:
http://dbsnake.com/2010/08/ora-600-4000-example.html
在网上能搜到的最早处理这个问题的个人应该logzgh，这哥们目前在淘宝。
链接:http://logzgh.itpub.net/post/3185/191423