sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 故障案例 >

【案例】Oracle报错ORA-00600 [4000]终极官方推荐解决方法

时间:2016-11-16 21:14   来源:Oracle研究中心   作者:网络   点击:

天萃荷净 Oracle研究中心案例分析:运维DBA反映Oracle数据库出现报错ORA-00600 [4000],通过反复重启数据库无法启动,使用BBED或UE来修复块中数据解决该问题。
本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: ora-600 4000恢复一例

下午一个同事遇到经典的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 
            http://www.oracleplus.net                                       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#          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即可,如下:

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

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【案例】Oracle报错ORA-00600 [4000]终极官方推荐解决方法

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1285.html

Oracle研究中心

关键词:

ORA-00600

ORA-00600 [4000]

Oracle重启不能解决ORA-00600 [4000]错误