首先,我使用的是Oracle10.2版本Oracle运行后,bdump中出现以下错误提示:Mon May 11 22:24:26 2009
Errors in file c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2908.trc:
ORA-00600: internal error code, arguments: [KGHALP1], [0x0], [], [], [], [], [], []Mon May 11 22:24:28 2009
Errors in file c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2616.trc:
ORA-00600: internal error code, arguments: [KGHALP1], [0x0], [], [], [], [], [], []引用udump中的文件,在附件中上传不了(不知道什么原因,每次发帖都不能上传附件,郁闷啊)只能在下面的两个帖子中贴部分出来。

解决方案 »

  1.   

    Dump file c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2616.trc
    Mon May 11 22:24:28 2009
    ORACLE V10.2.0.1.0 - Production vsnsta=0
    vsnsql=14 vsnxtr=3
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    Windows XP Version V5.1 Service Pack 2
    CPU                 : 1 - type 586
    Process Affinity    : 0x00000000
    Memory (Avail/Total): Ph:95M/399M, Ph+PgF:338M/798M, VA:1626M/2047M
    Instance name: orclRedo thread mounted by this instance: 1Oracle process number: 22Windows thread id: 2616, image: ORACLE.EXE (SHAD)
    kghalp bad size 0x5f485455
    ***** Internal heap ERROR KGHALP1 addr=00000000 ds=08B26630 *****
    ******************************************************
    HEAP DUMP heap name="Alloc server h"  desc=08B26630
     extent sz=0x1024 alt=32767 het=32767 rec=0 flg=2 opc=2
     parent=08B27BAC owner=00000000 nex=00000000 xsz=0x4b8
    EXTENT 0 addr=08B26BC4
      Chunk  8b26bcc sz=     1028    perm      "perm           "  alo=80
      Chunk  8b26fd0 sz=       28    freeable assoc with  prv=00000000 nxt=00000000
      Chunk  8b26fec sz=      144    freeable assoc with  prv=00000000 nxt=00000000
    Total heap size    =     1200
    FREE LISTS:
     Bucket 0 size=144
     Bucket 1 size=272
     Bucket 2 size=528
     Bucket 3 size=1040
     Bucket 4 size=2064
     Bucket 5 size=4112
     Bucket 6 size=16400
     Bucket 7 size=32784
    Total free space   =        0
    UNPINNED RECREATABLE CHUNKS (lru first):
    PERMANENT CHUNKS:
      Chunk  8b26bcc sz=     1028    perm      "perm           "  alo=80
    Permanent space    =     1028
    MARKS:
      Mark 08B26C08
    ******************************************************
     Hla: 255
    *** 2009-05-11 22:24:28.405
    ksedmp: internal or fatal error
    ORA-00600: internal error code, arguments: [KGHALP1], [0x0], [], [], [], [], [], []
    Current SQL information unavailable - no session.
    ----- Call Stack Trace -----
    calling              call     entry                argument values in hex      
    location             type     point                (? means dubious value)     
    -------------------- -------- -------------------- ----------------------------
    _ksedst+38           CALLrel  _ksedst1+0           0 1
    _ksedmp+898          CALLrel  _ksedst+0            0
    _ksfdmp+14           CALLrel  _ksedmp+0            3
    _kgerinv+140         CALLreg  00000000             1027DBB8 3
    _kgesinv+36          CALLrel  _kgerinv+0           1027DBB8 9030020 6079774C 1
                                                       B30D874
    _kgesin+19           CALLrel  _kgesinv+0           1027DBB8 9030020 6079774C 1
                                                       B30D874
    _kghnerror+773       CALLrel  _kgesin+0            1027DBB8 9030020 6079774C 1 2
                                                       0
    _kghalp+343          CALLrel  _kghnerror+0         1027DBB8 8B26630 6079774C 0
                                                       1027DBB8 60797730 5F485455
    _kpuhhalp+228        CALLrel  _kghalp+0            1027DBB8 8B26630 5F485455
                                                       1000000 0 61086184
    _ttcrbur+1391        CALLreg  00000000             10283F78 5F485455 61086184
    _ttcbur+296          CALLrel  _ttcrbur+0           1027DBB8 10283FF8 B30E224 64
                                                       0 0 0 610835EC
    _ttcpip+3967         CALLreg  00000000             1027DBB8 10283FF8 B30E224 64
                                                       197 0 0 0
    _opitsk+1017         CALL???  00000000             
    _opiino+1087         CALLrel  _opitsk+0            0 0
    _opiodr+1099         CALLreg  00000000             3C 4 B30FC8C
    _opidrv+819          CALLrel  _opiodr+0            3C 4 B30FC8C 0
    _sou2o+45            CALLrel  _opidrv+0            3C 4 B30FC8C
    _opimai_real+112     CALLrel  _sou2o+0             B30FC80 3C 4 B30FC8C
    _opimai+92           CALLrel  _opimai_real+0       2 B30FCB8
    _OracleThreadStart@  CALLrel  _opimai+0            
    4+708                                              
    7C80B508             CALLreg  00000000             
     
    --------------------- Binary Stack Dump ---------------------
     
    ========== FRAME [1] (_ksedst+38 -> _ksedst1+0) ==========
    Dump of memory from 0x0B30D724 to 0x0B30D734
    B30D720          0B30D734 0040468B 00000000      [4.0..F@.....]
    B30D730 00000001                             [....]            
    ========== FRAME [2] (_ksedmp+898 -> _ksedst+0) ==========
    Dump of memory from 0x0B30D734 to 0x0B30D7F4
    B30D730          0B30D7F4 00403083 00000000      [..0..0@.....]
    B30D740 0B30D754 608ED8E3 0B30D768 60796438  [T.0....`h.0.8dy`]
    B30D750 0B30D764 0B30D7AC 60724DB7 1027E051  [d.0...0..Mr`Q.'.]
    B30D760 0B30D768 00000003 00307830 00000000  [h.0.....0x0.....]
    B30D770 00000000 00000000 00000000 00000000  [................]
    B30D780 00000000 00000000 09658F34 00000000  [........4.e.....]
    B30D790 096595B6 00000003 1027DCBC 1027DCB4  [..e.......'...'.]
    B30D7A0 6079774C FFFFFFFF 000007EC 0B30D7F0  [Lwy`..........0.]
    B30D7B0 00000001 00000000 00000000 00000000  [................]
    B30D7C0 00000001 00000000 00000000 1027DBB8  [..............'.]
    B30D7D0 09030020 031DAC40 00000001 0B30D740  [ ...@[email protected].]
    B30D7E0 1027DBB8 0B30D988 0261348C 031C1800  [..'...0..4a.....]
    B30D7F0 FFFFFFFF                             [....]            
    ========== FRAME [3] (_ksfdmp+14 -> _ksedmp+0) ==========
    Dump of memory from 0x0B30D7F4 to 0x0B30D800
    B30D7F0          0B30D800 0043AB6F 00000003      [..0.o.C.....]
    ========== FRAME [4] (_kgerinv+140 -> 00000000) ==========
    Dump of memory from 0x0B30D800 to 0x0B30D81C
    B30D800 0B30D81C 603A8238 1027DBB8 00000003  [..0.8.:`..'.....]
    B30D810 1027DBB8 09030020 00421664           [..'. ...d.B.]    
    ========== FRAME [5] (_kgesinv+36 -> _kgerinv+0) ==========
    Dump of memory from 0x0B30D81C to 0x0B30D840
    B30D810                            0B30D840              [@.0.]
    B30D820 603A845B 1027DBB8 09030020 6079774C  [[.:`..'. ...Lwy`]
    B30D830 00000001 0B30D874 1027DBB8 00000000  [....t.0...'.....]
    ========== FRAME [6] (_kgesin+19 -> _kgesinv+0) ==========
    Dump of memory from 0x0B30D840 to 0x0B30D85C
    B30D840 0B30D85C 603A828E 1027DBB8 09030020  [\.0...:`..'. ...]
    B30D850 6079774C 00000001 0B30D874           [Lwy`....t.0.]    
    ========== FRAME [7] (_kghnerror+773 -> _kgesin+0) ==========
      

  2.   

    Dump file c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2908.trc
    Mon May 11 22:24:26 2009
    ORACLE V10.2.0.1.0 - Production vsnsta=0
    vsnsql=14 vsnxtr=3
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    Windows XP Version V5.1 Service Pack 2
    CPU                 : 1 - type 586
    Process Affinity    : 0x00000000
    Memory (Avail/Total): Ph:99M/399M, Ph+PgF:339M/798M, VA:1629M/2047M
    Instance name: orclRedo thread mounted by this instance: 1Oracle process number: 21Windows thread id: 2908, image: ORACLE.EXE (SHAD)
    kghalp bad size 0x5f485455
    ***** Internal heap ERROR KGHALP1 addr=00000000 ds=08986630 *****
    ******************************************************
    HEAP DUMP heap name="Alloc server h"  desc=08986630
     extent sz=0x1024 alt=32767 het=32767 rec=0 flg=2 opc=2
     parent=08987BAC owner=00000000 nex=00000000 xsz=0x4b8
    EXTENT 0 addr=08986BC4
      Chunk  8986bcc sz=     1028    perm      "perm           "  alo=80
      Chunk  8986fd0 sz=       28    freeable assoc with  prv=00000000 nxt=00000000
      Chunk  8986fec sz=      144    freeable assoc with  prv=00000000 nxt=00000000
    Total heap size    =     1200
    FREE LISTS:
     Bucket 0 size=144
     Bucket 1 size=272
     Bucket 2 size=528
     Bucket 3 size=1040
     Bucket 4 size=2064
     Bucket 5 size=4112
     Bucket 6 size=16400
     Bucket 7 size=32784
    Total free space   =        0
    UNPINNED RECREATABLE CHUNKS (lru first):
    PERMANENT CHUNKS:
      Chunk  8986bcc sz=     1028    perm      "perm           "  alo=80
    Permanent space    =     1028
    MARKS:
      Mark 08986C08
    ******************************************************
     Hla: 255
    *** 2009-05-11 22:24:26.139
    ksedmp: internal or fatal error
    ORA-00600: internal error code, arguments: [KGHALP1], [0x0], [], [], [], [], [], []
    Current SQL information unavailable - no session.
    ----- Call Stack Trace -----
    calling              call     entry                argument values in hex      
    location             type     point                (? means dubious value)     
    -------------------- -------- -------------------- ----------------------------
    _ksedst+38           CALLrel  _ksedst1+0           0 1
    _ksedmp+898          CALLrel  _ksedst+0            0
    _ksfdmp+14           CALLrel  _ksedmp+0            3
    _kgerinv+140         CALLreg  00000000             EC844B8 3
    _kgesinv+36          CALLrel  _kgerinv+0           EC844B8 8A10020 6079774C 1
                                                       9E3D874
    _kgesin+19           CALLrel  _kgesinv+0           EC844B8 8A10020 6079774C 1
                                                       9E3D874
    _kghnerror+773       CALLrel  _kgesin+0            EC844B8 8A10020 6079774C 1 2
                                                       0
    _kghalp+343          CALLrel  _kghnerror+0         EC844B8 8986630 6079774C 0
                                                       EC844B8 60797730 5F485455
    _kpuhhalp+228        CALLrel  _kghalp+0            EC844B8 8986630 5F485455
                                                       1000000 0 61086184
    _ttcrbur+1391        CALLreg  00000000             EC8A878 5F485455 61086184
    _ttcbur+296          CALLrel  _ttcrbur+0           EC844B8 EC8A8F8 9E3E224 64 0
                                                       0 0 610835EC
    _ttcpip+3967         CALLreg  00000000             EC844B8 EC8A8F8 9E3E224 64
                                                       197 0 0 0
    _opitsk+1017         CALL???  00000000             
    _opiino+1087         CALLrel  _opitsk+0            0 0
    _opiodr+1099         CALLreg  00000000             3C 4 9E3FC8C
    _opidrv+819          CALLrel  _opiodr+0            3C 4 9E3FC8C 0
    _sou2o+45            CALLrel  _opidrv+0            3C 4 9E3FC8C
    _opimai_real+112     CALLrel  _sou2o+0             9E3FC80 3C 4 9E3FC8C
    _opimai+92           CALLrel  _opimai_real+0       2 9E3FCB8
    _OracleThreadStart@  CALLrel  _opimai+0            
    4+708                                              
    7C80B508             CALLreg  00000000             
     
    --------------------- Binary Stack Dump ---------------------
     
    ========== FRAME [1] (_ksedst+38 -> _ksedst1+0) ==========
    Dump of memory from 0x09E3D724 to 0x09E3D734
    9E3D720          09E3D734 0040468B 00000000      [4....F@.....]
    9E3D730 00000001                             [....]            
    ========== FRAME [2] (_ksedmp+898 -> _ksedst+0) ==========
    Dump of memory from 0x09E3D734 to 0x09E3D7F4
    9E3D730          09E3D7F4 00403083 00000000      [.....0@.....]
    9E3D740 09E3D754 608ED8E3 09E3D768 60796438  [T......`h...8dy`]
    9E3D750 09E3D764 09E3D7AC 60724DB7 0EC84951  [d........Mr`QI..]
    9E3D760 09E3D768 00000003 00307830 00000000  [h.......0x0.....]
    9E3D770 00000000 00000000 00000000 00000000  [................]
    9E3D780 00000000 00000000 09098F34 00000000  [........4.......]
    9E3D790 090995B6 00000003 0EC845BC 0EC845B4  [.........E...E..]
    9E3D7A0 6079774C FFFFFFFF 000007EC 09E3D7F0  [Lwy`............]
    9E3D7B0 00000001 00000000 00000000 00000000  [................]
    9E3D7C0 00000001 00000000 00000000 0EC844B8  [.............D..]
    9E3D7D0 08A10020 031DAC40 00000001 09E3D740  [ ...@.......@...]
    9E3D7E0 0EC844B8 09E3D988 0261348C 031C1800  [.D.......4a.....]
    9E3D7F0 FFFFFFFF                             [....]            
    ========== FRAME [3] (_ksfdmp+14 -> _ksedmp+0) ==========
    Dump of memory from 0x09E3D7F4 to 0x09E3D800
    9E3D7F0          09E3D800 0043AB6F 00000003      [....o.C.....]
    ========== FRAME [4] (_kgerinv+140 -> 00000000) ==========
    Dump of memory from 0x09E3D800 to 0x09E3D81C
    9E3D800 09E3D81C 603A8238 0EC844B8 00000003  [....8.:`.D......]
    9E3D810 0EC844B8 08A10020 00421664           [.D.. ...d.B.]    
    ========== FRAME [5] (_kgesinv+36 -> _kgerinv+0) ==========
    Dump of memory from 0x09E3D81C to 0x09E3D840
    9E3D810                            09E3D840              [@...]
    9E3D820 603A845B 0EC844B8 08A10020 6079774C  [[.:`.D.. ...Lwy`]
    9E3D830 00000001 09E3D874 0EC844B8 00000000  [....t....D......]
    ========== FRAME [6] (_kgesin+19 -> _kgesinv+0) ==========
    Dump of memory from 0x09E3D840 to 0x09E3D85C
    9E3D840 09E3D85C 603A828E 0EC844B8 08A10020  [\.....:`.D.. ...]
    9E3D850 6079774C 00000001 09E3D874           [Lwy`....t...]    
    ========== FRAME [7] (_kghnerror+773 -> _kgesin+0) ==========
    Dump of memory from 0x09E3D85C to 0x09E3D894
    9E3D850                            09E3D894              [....]
    9E3D860 603B22A8 0EC844B8 08A10020 6079774C  [.";`.D.. ...Lwy`]
    9E3D870 00000001 00000002 00000000 000000FF  [................]
    9E3D880 00000000 0EC845B4 08986630 0EC844B8  [.....E..0f...D..]
    9E3D890 603B1FAB                             [..;`]            
    ========== FRAME [8] (_kghalp+343 -> _kghnerror+0) ==========
    Dump of memory from 0x09E3D894 to 0x09E3D8FC
    9E3D890          09E3D8FC 603BE254 0EC844B8      [....T.;`.D..]
    9E3D8A0 08986630 6079774C 00000000 0EC844B8  [0f..Lwy`.....D..]
    9E3D8B0 60797730 5F485455 7C92FB6C 7C92FB71  [0wy`UTH_l..|q..|]
    9E3D8C0 00000001 00000000 00000000 00000000  [................]
    9E3D8D0 0EC844B8 0EC845B4 5F485455 0EC845B4  [.D...E..UTH_.E..]
    9E3D8E0 000000CB 08986630 00000001 0EC845B4  [....0f.......E..]
    9E3D8F0 C0000023 00000000 603BE105           [#.........;`]    
      

  3.   

    请问,这些trace文件应该如何分析,这个问题应该如何解决?
      

  4.   

    这个是oracle bug,具体的原因可能是因为某个语句没有commit诸如此类的错误发生的。
      

  5.   

    那请问下:KGHALP1是个什么概念啊?我不懂。
      

  6.   

    一个BUG.主题:  ORA-600 [kghalp1]
      文档 ID:  285598.1 类型:  REFERENCE
      上次修订日期:  07-SEP-2007 状态:  PUBLISHED
    Note: For additional ORA-600 related information please read Note 146580.1PURPOSE:
      This article represents a partially published OERI note.  It has been published because the ORA-600 error has been
      reported in at least one confirmed bug.  Therefore, the SUGGESTIONS section of this article may help
      in terms of identifying the cause of the error.  This specific ORA-600 error may be considered for full publication
      at a later date. If/when fully published, additional information
      will be available here on the nature of this error.SUGGESTIONS:  If the Known Issues section below does not help in terms of identifying
      a solution, please submit the trace files and alert.log to Oracle
      Support Services for further analysis.  Known Issues:
      Bug# 4053658   See Note 4053658.8
          OERI:KGHALP1 / OERI:733 for large elements in XDB
          Fixed: 10.2.0.1  Bug# 3854134   See Note 3854134.8
          OERI:KGHALP1 with JDBC clients accessing HS datasource
          Fixed: 10.1.0.5, 10.2.0.1  Bug# 3649683   See Note 3649683.8
          OERI:KGHALO2 / OERI:KGHALP1 on a query with large number of predicates
          Fixed: 9.2.0.6, 10.1.0.4, 10.2.0.1  Bug# 2708874   See Note 2708874.8
          OERI:KGHALP1 / ORA-4030 using FORALL with SAVE EXCEPTIONS
          Fixed: 9.2.0.6, 10.1.0.4, 10.2.0.1
      

  7.   

    上面的文档无法准确定位错误,ORACLE在执行什么工作的时候出现错误,是否RMAN?.另外,需要把相关的配置说明一下,才能够确认.
      

  8.   

    遇过类似的错误,上metalink查过确认是bug引起的
      

  9.   

    ORA-600 [KGHALP1] Error Executing a Join Query with Dynamic Sampling Enabled 
      文档 ID:  465261.1 类型:  PROBLEM 
      上次修订日期:  14-MAY-2008 状态:  REVIEWED In this Document
      Symptoms
      Changes
      Cause
      Solution
      References--------------------------------------------------------------------------------Applies to: 
    Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3
    This problem can occur on any platform.Symptoms
    ORA-600 [KGHALP1] error raised when trying to allocate memory in the "kxs-heap-c" heap when executing a join query.
    The call stack from the trace file includes module kkedsamp() indicating that optimizer dynamic sampling is being performed.Changes
    OPTIMIZER_DYNAMIC_SAMPLING parameter is set to 4 or higher. 
    Cause
    This is due to Bug 5976822 fixed in 11.1 where a poor execution plan can be chosen when using dynamic sampling and an index access path is available.Solution
    This bug has been fixed in version 11.1 and back ported to the 10.2.0.4 patchset.  To resolve this problem either download and apply the one-off patch for Bug 5976822 if available for your version/platform.  Alternatively the issue can be worked around by setting optimizer dynamic sampling to a value less than 4, e.g.:      connect / as sysdba
          alter system set optimizer_dynamic_sampling = 1 scope=both;References
    Bug 5976822 - BAD ACCESSPLAN FOR MERGE WHEN OPTIMIZER_DYNAMIC_SAMPLING = 4
    Note 285598.1 - ORA-600 [kghalp1]Keywords
    JITLIST; KGHALP1; OERI; 
      

  10.   

    ORA-600 [KGHALP1] error raised when trying to allocate memory in the "kxs-heap-c" heap when executing a join query. 
    The call stack from the trace file includes module kkedsamp() indicating that optimizer dynamic sampling is being performed. TRC中貌似没有发现这个.
      

  11.   

    根据call stack ,应该与mv这里有一定的关系哦.但这这个需要test case.楼主不提供信息
      

  12.   

    貌似WINDOWS系统的问题一般都比较奇怪, 测试环境居多,一般也不是重要的系统. ORACLE支持的CASE很少.