--【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: oracle@oracledb

*** 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最简单定时清除日志