ora-6000 4000恢复一例
<DIV><FONT color=#f00000>原文链接 个人博客 </FONT><a href="http://www.killdb.com/?p=225" _xhe_href="http://www.killdb.com/?p=225" target="_blank"><FONT color=#f00000>http://www.killdb.com/?p=225</FONT></A><P>下午一个同事遇到经典的ora-600 4000错误,我远程帮忙处理了一下,关于该错误的处理,<BR>网上已经有不少的例子了,通常情况下,该错误通过反复重启数据库,然后可以进行规避<BR>4000错误,但是如果反复重启N次后,错误依旧的话,那么我们只能使用极端手段了。<BR>网上能找到的例子基本上都是一个思路,通过trace 定位到含未提交视图的block,<BR>然后用bbed(windows可以使用UE代替)修改flag,将20修改为80即可,如下:<BR>*** 2011-08-30 15:57:10.037<BR>ksedmp: internal or fatal error<BR>ORA-00600: internal error code, arguments: , , [], [], [], [], [], []<BR>Current SQL statement for this session:<BR>select ctime, mtime, stime from obj$ where obj# = :1<BR>----- Call Stack Trace -----<BR>calling call entry argument values in hex <BR>location type point (? means dubious value) <BR>-------------------- -------- -------------------- ----------------------------<BR>ksedst()+27 call ksedst1() 0 ? 1 ?<BR>ksedmp()+557 call ksedst() 0 ? 9BF6BA9C ? 0 ? 2A ?<BR> 955B3FF0 ? 70000 ?<BR>ksfdmp()+19 call ksedmp() 3 ? BFA3EF80 ? AC152B0 ?<BR> CBD2D20 ? 3 ? CB84398 ?<BR>kgeriv()+188 call 00000000 CBD2D20 ? 3 ?<BR>kgeasi()+113 call kgeriv() CBD2D20 ? B7F50020 ? FA0 ?<BR> 1 ? BFA3EFBC ?<BR>ktudba()+264 call kgeasi() CBD2D20 ? B7F50020 ? FA0 ?<BR> 2 ? 1 ? 0 ? 5 ? 0 ?<BR>ktrgcm()+6207 call ktudba() 5 ? BFA3F49C ? 0 ? 0 ?<BR>ktrgtc()+941 call ktrgcm() B7F6A3A0 ? 0 ? B7F9EC60 ?<BR> 8EF1A0B4 ? 8EF10CE8 ? 198 ?<BR>kdsgrp()+107 call ktrgtc() B7F6A3A0 ? B7F6A348 ?<BR> 9C22152 ? BFA3F5B8 ? 240 ?<BR> 9C24DD4 ? 9C21D8C ?<BR>kdsfbrcb()+513 call kdsgrp() B7F6A39C ? 0 ? B7F6A39C ?<BR>qertbFetchByRowID() call kdsfbrcb() B7F6A39C ? B7F9EBF8 ? 0 ? 1 ?<BR>+2052 0 ? 0 ?<BR>opifch2()+5157 call 00000000 8EF10A8C ? A11CDF4 ?<BR> BFA3FBE4 ? 1 ?<BR>opifch()+56 call opifch2() 89 ? 5 ? BFA3FE54 ?<BR>opiodr()+2347 call 00000000 5 ? 2 ? BFA40BD0 ?<BR>rpidrus()+434 call opiodr() 5 ? 2 ? BFA40BD0 ? 5 ?<BR>skgmstack()+210 call 00000000 BFA4062C ? CBD2E1C ?<BR> CBD2E1C ? BFA40610 ?<BR> BFA40B14 ? BFA4062C ?<BR>rpidru()+98 call skgmstack() BFA40610 ? CBD2AE0 ? F618 ?<BR> 9749536 ? BFA4062C ?<BR>rpiswu2()+1061 call 00000000 BFA40B14 ? BFA40C60 ? 2 ? 2 ?<BR> BFA40AD8 ? 5953 ?<BR>rpidrv()+1915 call rpiswu2() 99C70654 ? 0 ? BFA40AD8 ? 2 ?<BR> BFA40B50 ? 0 ? BFA40AD8 ? 0 ?<BR> 97497F0 ? 97498CC ?<BR> BFA40B14 ? 8 ?<BR>rpifch()+56 call rpidrv() 5 ? 5 ? BFA40BD0 ? 8 ?<BR>kqdpts()+174 call rpifch() 5 ? 5 ? 5 ? 3 ? 9AB69FDB ?<BR> 7 ?<BR>kqrlfc()+534 call kqdpts() 9AB69E4C ? BFA40E10 ? 35953 ?<BR> CBD2E1C ? CBD2D20 ? 8 ?<BR>kqlbplc()+107 call kqrlfc() 0 ? BFA40DF8 ? 4 ? 0 ?<BR> C251F20 ? 47 ?<BR>kqlblfc()+477 call kqlbplc() 0 ? BFA42734 ? 9CCC2088 ?<BR> CBD2E1C ? CBD2D20 ? 7 ?<BR>adbdrv()+5689 call kqlblfc() 0 ? BFA45508 ?<BR>opiexe()+18301 call adbdrv() 23288 ? 0 ? 18E19E2E ?<BR> 48FAE ? 9AB70BC4 ? 0 ?<BR>opiosq0()+3918 call opiexe() 4 ? 0 ? BFA46978 ?<BR>kpooprx()+250 call opiosq0() 3 ? E ? BFA46B80 ? A4 ?<BR>kpoal8()+867 call kpooprx() BFA48D58 ? BFA478F0 ? 1D ?<BR> 1 ? 0 ? A4 ?<BR>opiodr()+2347 call 00000000 5E ? 17 ? BFA48D54 ?<BR>ttcpip()+4227 call 00000000 5E ? 17 ? BFA48D54 ? 0 ?<BR> CD51D86 ? 11 ?<BR>opitsk()+1991 call ttcpip() CBDA520 ? 5E ? BFA48D54 ? 0 ?<BR> BFA48234 ? BFA48E78 ?<BR>opiino()+1387 call opitsk() 0 ? 0 ?<BR>opiodr()+2347 call 00000000 3C ? 4 ? BFA49940 ?<BR>opidrv()+915 call opiodr() 3C ? 4 ? BFA49940 ? 0 ?<BR>sou2o()+113 call opidrv() 3C ? 4 ? BFA49940 ?<BR>opimai_real()+212 call sou2o() BFA49924 ? 3C ? 4 ?<BR> BFA49940 ?<BR>main()+111 call opimai_real() 2 ? BFA49970 ?<BR>__libc_start_main() call 00000000 2 ? BFA49A34 ? BFA49A40 ?<BR>+220 4FFAC2 ? 0 ? 12D798 ?</P>
<DIV class=entry>从上面错误来看,我们知道问题出在访问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.3a7f4d35data_block_dump,data header at 0x847ce044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x847ce044
<FONT color=#0000ff>bdba: 0x0040007a</FONT>
76543210
flag=--------
ntab=1
nrow=108
frre=-1
fsbo=0xea
fseo=0x385
avsp=0x369
tosp=0x369
0xe:pti nrow=108 offs=0
上面的信息比较关键,关于XID,UBA的解释,我以前也写过相关文章,这里不多说。
<FONT color=#0000ff>通过bdba: 0x0040007a 我们可以通过如下查询,得知为file 1 block 122.</FONT>
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, 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
<FONT color=#0000ff>ub2 ktbitflg @60 0x2001 (KTBFUPB)</FONT>
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错误,详见如下链接:
<a href="http://dbsnake.com/2010/08/ora-600-4000-example.html" _xhe_href="http://dbsnake.com/2010/08/ora-600-4000-example.html" target="_blank">http://dbsnake.com/2010/08/ora-600-4000-example.html</A>
在网上能搜到的最早处理这个问题的个人应该logzgh,这哥们目前在淘宝。
链接:http://logzgh.itpub.net/post/3185/191423</DIV></DIV>
页:
[1]