ora-600 4000恢复一例
本站文章除注明转载外，均为本站原创： 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: ora-600 4000恢复一例
下午一个同事遇到经典的ora-600 4000错误，我远程帮忙处理了一下，关于该错误的处理，
网上已经有不少的例子了，通常情况下，该错误通过反复重启数据库，然后可以进行规避
4000错误，但是如果反复重启N次后，错误依旧的话，那么我们只能使用极端手段了。
网上能找到的例子基本上都是一个思路，通过trace 定位到含未提交视图的block，
然后用bbed(windows可以使用UE代替)修改flag，将20修改为80即可，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
*** 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。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
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.
|
1 2 3 |
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，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
BBED> set file 1 block 122 FILE# 1 BLOCK# 122 BBED> 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 |
上面的ktbitxid 即为XID的，ktbituba即为UBA，其他的不多说。
这里主要是要修改 ktbitflg，该结构其实占据了2个offset。
修改的时候需要注意一下的是要看os是32位还是64位，32位的话，其字节序是反的。
我这里就直接执行modify /x 8001 offset 60 然后sum apply即可。
然后再重启数据库 直接open，发现不再出现4000错误了，而是2663,这个好办，
该错误跟2662 类似，直接调整scn即可，如下：
|
1 |
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
One Response to “ora-600 4000恢复一例”
[…] http://www.killdb.com/?p=225 下午一个同事遇到经典的ora-600 […]
Leave a Reply
You must be logged in to post a comment.