【ORA-00600: internal error code, arguments: [6305], [23], [22], [1] 總結】

--【ORA-00600: internal error code, arguments: [6305], [23], [22], [1] 總結】
--第一步 看看跟蹤檔案的主要資訊
--1 看到是查詢引600錯誤 知道要好好看看跟蹤檔案 --先忙是跟蹤檔案的頭部，檢視檔案頭部是必須的
System name: Linux
Node name: oracledb
Release: 2.6.18-92.el5
Version: #1 SMP Fri May 23 23:40:43 EDT 2008
Machine: x86_64
Instance name: oraweb
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 29544, image:

*** 2011-11-10 00:20:18.869
*** SESSION ID:(128.24024) 2011-11-10 00:20:18.869
*** CLIENT ID:() 2011-11-10 00:20:18.869
*** SERVICE NAME:(SYS$USERS) 2011-11-10 00:20:18.869
*** MODULE NAME:(JDBC Thin Client) 2011-11-10 00:20:18.869
*** ACTION NAME:() 2011-11-10 00:20:18.869

Dump continued from file: /trace/oraweb_ora_29544.trc
ORA-00600: internal error code, arguments: [6305], [23], [22], [1], [], [], [], []

========= Dump for incident 37069 (ORA 600 [6305]) ========

*** 2011-11-10 00:20:18.869
----- Current SQL Statement for this session (sql_id=0wj43d03azdw7) -----
select tyzl0_.TBTH as TBTH7_0_, tyzl0_.XH as XH7_0_, tyzl0_.XM as XM7_0_, tyzl0_.XB as XB7_0_, tyzl0_.CSRQ as CSRQ7_0_, tyzl0_.GJDQ as GJDQ7_0_, tyzl0_.ZJLB as ZJLB7_0_, tyzl0_.ZJHM as ZJHM7_0_, tyzl0_.D2XM as D9_7_0_, tyzl0_.D2CSRQ as D10_7_0_, tyzl0_.D2ZL as D11_7_0_, tyzl0_.D2ZH as D12_7_0_, tyzl0_.CJSY as CJSY7_0_, tyzl0_.RJSY as RJSY7_0_, tyzl0_.QZQZDM as QZQZDM7_0_, tyzl0_.SJZQX as SJZQX7_0_, tyzl0_.BZ as BZ7_0_ from tabbane tyzl0_ where tyzl0_.TBTH=:1 and tyzl0_.XH=:2

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+41 call kgdsdst() 000000000 ? 000000001 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000000 ? 000000002 ?
ksedst1()+103 call skdstdst() 000000000 ? 000000001 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
ksedst()+39 call ksedst1() 000000000 ? 000000001 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
dbkedDefDump()+1076 call ksedst() 000000000 ? 000000001 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
ksedmp()+41 call dbkedDefDump() 000000003 ? 000000002 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
ksfdmp()+27 call ksedmp() 000000003 ? 000000002 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
dbgexPhaseII()+1043 call ksfdmp() 000000003 ? 000000002 ?
7FFF2A06BF68 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
dbgexProcessError() call dbgexPhaseII() 2B9181AAC6A8 ? 2B9181C1D0E8 ?
+989 7FFF2A072EA8 ? 7FFF2A06AA50 ?
000000001 ? 000000002 ?
dbgeExecuteForError call dbgexProcessError() 2B9181AAC6A8 ? 2B9181C1D0E8 ?
()+67 000000001 ? 000000000 ?
100000000 ? 000000002 ?
dbgePostErrorKGE()+ call dbgeExecuteForError 2B9181AAC6A8 ? 2B9181C1D0E8 ?
1774 () 000000001 ? 000000001 ?
000000000 ? 000000002 ?
dbkePostKGE_kgsf()+ call dbgePostErrorKGE() 0097CD120 ? 2B9181CB2040 ?
64 000000258 ? 2B9181C1D0E8 ?
000000000 ? 000000002 ?
kgeade()+354 call dbkePostKGE_kgsf() 0097CD120 ? 2B9181CB2040 ?
000000258 ? 2B9181C1D0E8 ?
000000000 ? 000000002 ?
kgeriv_int()+107 call kgeade() 0097CD120 ? 0097CD2D0 ?
2B9181CB2040 ? 000000258 ?
000000000 ? 000000002 ?
kgeriv()+20 call kgeriv_int() 0097CD120 ? 2B9181CB2040 ?
000000002 ? 000000258 ?
7FFF2A0739F0 ? 000000000 ?
kgeasi()+279 call kgeriv() 0097CD120 ? 2B9181CB2040 ?
000000002 ? 7FFF2A0739F0 ?
000000000 ? 000000000 ?
kdkoin()+1457 call kgeasi() 0097CD120 ? 2B9181CB2040 ?
000000002 ? 7FFF2A0739F0 ?
000000000 ? 000000000 ?
kkpamRefGet()+1065 call kdkoin() 0097CD120 ? 000000003 ?
000000002 ? 000000000 ?
000000000 ? 000000000 ?
kkpamRefFGet()+326 call kkpamRefGet() 0A3D22428 ? 7FFF2A075BA0 ?
7FFF2A075CA8 ? 7FFF2A075CEC ?
000000000 ? 0A3D22780 ?
kkpamFRange()+1402 call kkpamRefFGet() 0A3D22428 ? 7FFF2A075CEC ?
7FFF2A075CA8 ? 7FFF2A075CEC ?
000000000 ? 0A3D22780 ?
kkpapFMParts()+57 call kkpamFRange() 0A3D22428 ? 0A3D1EFE8 ?
7FFF2A075FE4 ? 000000000 ?
0A3D1EFE8 ? 7FFF2A075FE0 ?
kkpapbGetRange()+10 call kkpapFMParts() 0A3D22428 ? 0A3D1EFE8 ?
52 7FFF2A075FE4 ? 000000000 ?
0A3D1EFE8 ? 7FFF2A075FE0 ?
kkpapGRangeSLvl()+4 call kkpapbGetRange() 0A3D21F48 ? 000000016 ?
03 0A3D226F8 ? 7FFF2A076058 ?
7FFF2A076054 ? 7FFF2A076050 ?
kkpapiItOpen()+210 call kkpapGRangeSLvl() 0A3D21FB0 ? 0A3D22428 ?
000000002 ? 7FFF2A076474 ?
7FFF2A076470 ? 7FFF2A07646C ?
kkpapItOpen()+289 call kkpapiItOpen() 2B9181D0DBC8 ? 2B9181D0DBD8 ?
0A3D21FB0 ? 0A3D22428 ?
000000000 ? 000000002 ?
qertbItOpen()+137 call kkpapItOpen() 0A3D21FB0 ? 2B9181D0DBC8 ?
000000002 ? 000000002 ?
2B9100000000 ? 000000000 ?
qertbStart()+1727 call qertbItOpen() 0A3D200E0 ? 2B9181CF7DB0 ?
000000002 ? 000000002 ?
2B9100000000 ? 000000000 ?
selexe0()+1064 call qertbStart() 0A3D1FFD0 ? 2B9181CF7CF8 ?
000000001 ? 0A3D22F40 ?
2B9100000000 ? 000000000 ?
opiexe()+15086 call selexe0() 0A3D22F40 ? 7FFF2A077060 ?
7FFF2A076E18 ? 000000001 ?
2B9100000000 ? 0A3D22F40 ?
kpoal8()+2805 call opiexe() 000000049 ? 000000003 ?
7FFF2A077AB0 ? 000000001 ?
2B9100000000 ? 0A3D22F40 ?
opiodr()+1178 call kpoal8() 00000005E ? 00000001C ?
7FFF2A07AE80 ? 000000001 ?
000000001 ? 0A3D22F40 ?
ttcpip()+1211 call opiodr() 00000005E ? 00000001C ?
7FFF2A07AE80 ? 000000000 ?
008222AF0 ? 0A3D22F40 ?
opitsk()+1455 call ttcpip() 0097DF3B0 ? 007819C90 ?
7FFF2A07AE80 ? 000000000 ?
7FFF2A07A8E0 ? 7FFF2A07B06C ?
opiino()+1026 call opitsk() 0097DF3B8 ? 000000000 ?
000000001 ? 000000000 ?
7FFF2A07A8E0 ? 7FFF2A07B06C ?
opiodr()+1178 call opiino() 00000003C ? 000000004 ?
7FFF2A07C4E8 ? 000000000 ?
7FFF2A07A8E0 ? 7FFF2A07B06C ?
opidrv()+580 call opiodr() 00000003C ? 000000004 ?
7FFF2A07C4E8 ? 000000000 ?
0082225A0 ? 7FFF2A07B06C ?
sou2o()+90 call opidrv() 00000003C ? 000000004 ?
7FFF2A07C4E8 ? 000000000 ?
0082225A0 ? 7FFF2A07B06C ?
opimai_real()+145 call sou2o() 7FFF2A07C4C0 ? 00000003C ?
000000004 ? 7FFF2A07C4E8 ?
0082225A0 ? 7FFF2A07B06C ?
ssthrdmain()+177 call opimai_real() 000000002 ? 7FFF2A07C660 ?
000000004 ? 7FFF2A07C4E8 ?
0082225A0 ? 7FFF2A07B06C ?
main()+215 call ssthrdmain() 000000002 ? 7FFF2A07C660 ?
000000004 ? 000000000 ?
0082225A0 ? 7FFF2A07B06C ?
__libc_start_main() call main() 000000002 ? 7FFF2A07C7C8 ?
+244 000000004 ? 000000000 ?
0082225A0 ? 7FFF2A07B06C ?
_start()+41 call __libc_start_main() 0009554B8 ? 000000002 ?
7FFF2A07C7C8 ? 000000000 ?
0082225A0 ? 000000002 ?
--2 檢視語句所在的程式資訊 找不到有用的資訊 後來發現0wj43d03azdw7 透過這個發現繫結變數 或許是解決問題的思考點 但是我也是後來找到根源後才知道（所以經驗積累很必要）
----- Bind Info (kkscoacd) -----
Bind#0
oacdty=01 mxl=128(44) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000010 frm=01 csi=852 siz=152 off=0
kxsbbbfp=2b9181cf1d40 bln=128 avl=22 flg=05
value="000165A201111171718112"
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=01 csi=852 siz=0 off=128
kxsbbbfp=2b9181cf1dc0 bln=22 avl=02 flg=01
value=1
Frames pfr 0x2b9181cf2180 siz=5832 efr 0x2b9181cf20b0 siz=5800
Cursor frame dump
enxt: 5.0x00000238 enxt: 4.0x000003a0 enxt: 3.0x00000040 enxt: 2.0x000000d8
enxt: 1.0x00000fb8
pnxt: 1.0x00000020
kxscphp=0x2b9181cd0568 siz=984 inu=408 nps=344
kxscbhp=0x2b9181cd0748 siz=984 inu=328 nps=176
kxscwhp=0x2b9181cd00b8 siz=4056 inu=160 nps=0
--這部分肯定有資訊 懷疑avl 是長度資訊 但僅僅是懷疑
--詳細檢視資訊發現
hp 10235 dflt
chk 10235 dflt
--oracle 11g的隱含引數資訊 10235是chunk heap 的檢查selective overrun 所以猜是 記憶體
--metlink上6305的錯誤 8i的 是主外來鍵 長度不一致引起的問題
_endprot_chunk_comment chk 10235 dflt chunk comment for selective overrun protection
_endprot_heap_comment hp 10235 dflt heap comment for selective overrun protection

0097CD270 31207068 35333230 6C666420 00000074 [hp 10235 dflt...]
0097CD280 206B6863 33323031 66642035 0000746C [chk 10235 dflt..]
0097CD290 00000101 DEADBEEF 00000001 00000000 [................]
0097CD2A0 80038000 00000000 C2341200 00000000 [..........4.....]
0097CD2B0 07904550 00000000 00001000 00000000 [PE..............]
0097CD2C0 81CB2040 00002B91 097D0D58 00000000 [@ ...+..X.}.....]
0097CD2D0 2A06F078 00007FFF 2A06F288 00007FFF [x..*.......*....]
0097CD2E0 81CB2040 00002B91 00000002 00000000 [@ ...+..........]
0097CD2F0 00000258 00000000 097CD9E4 00000000 [X.........|.....]
0097CD300 00000004 0000001D 00000000 00000000 [................]
0097CD310 00000000 00000000 00000000 00000000 [................]
Repeat 108 times
0097CD9E0 00000001 00000401 30333600 00020135 [.........6305...]
0097CD9F0 33320000 00000201 01323200 00000001 [..23.....22.....]
--還有就是堆疊資訊裡也可以看到，下面的是oracle內部東東 看的dbkePostKGE_kgsf 是做什麼用 實在不知道？？？？？？？？？？
========== FRAME [12] (kgeade()+354 -> dbkePostKGE_kgsf()) ==========
defined by frame pointers 0x7fff2a0738d0 and 0x7fff2a073800
CALL TYPE: call ERROR SIGNALED: no COMPONENT: (null)
RDI 00000000097CD120 RSI 00002B9181CB2040 RDX 0000000000000258
RCX 00002B9181C1D0E8 R8 0000000000000000 R9 0000000000000002
RAX 0000000000000001 RBX 0000000000000258 RBP 00007FFF2A0738C0
R10 0000000000000000 R11 0000000000000001 R12 00002B9181CB2040
R13 00000000097CD2D0 R14 00000000097CD120 R15 0000000000000000
RSP 00007FFF2A073800 RIP 00000000019533C4
Dump of memory from 0x7fff2a073800 to 0x7fff2a0738d0
7FFF2A073800 00000004 00000000 00000000 00000000 [................]
7FFF2A073810 00000000 00000000 00000003 00000000 [................]
7FFF2A073820 2A0739F0 00007FFF 822DDD98 00002B91 [.9.*......-..+..]
7FFF2A073830 35303336 00000000 2A074D78 00007FFF [6305....xM.*....]
--第二部
--我在網上 oraclefan上發了帖子 老白的懷疑 是data la用 全表掃描 看看是不是索引為您提
--測試不是原來以為僅僅是個別的 後來發現 改變數字 都會報錯誤
--10046失敗 autotrace失敗 systemstat 10沒有發現有用的資訊
--擔心應用問題就去了 幾個正常資料 查詢 沒有報錯
---------------------------------------------------
後來發現：
1 只查詢索引包含的欄位 不會報錯 如果加上索引以外的欄位 會有問題的
2 正常資料 怎麼查詢都是成功的
3 後來發現 查詢的where條件比正常表哥的大2個長度 所以報錯 測試一下 吧正確的也加兩個欄位報錯
4 想想metlink6305在8I的的長度有bug並且 資料庫猜在10235時錯誤 所以 應該可以肯定是bug 況且這個版本bug多
問題解決1 應用避免不正當的輸入，2 升級到穩定的資料庫版本 3最簡單定時清除日誌

[@more@]