http://yumianfeilong.com/2007/04 ... %e5%a4%aa%e5%a4%9a/
这是你的blog上的文章
里面提到
Oracle Bind Variable在Varchar2字段上存在一些坎儿,32,128,2000。意味着在应用中(N>2000),一个Varchar2(N),可以贡献4个不同的子游标。2个Varchar2(N)可以贡献7个子游标。如果一个表上有10个Varchar2(N)的子段,则可以贡献31个游标。就是SQL Version Count = 3*N + 1 如果表很多,有M个,就是SQL Version Count = 3*N*M + M
你后面给的tomkyte的文章也是这样的意思
可是在我这里却不是这样的
table T_ETYLOGFIELD
(
LOGID VARCHAR2(50 BYTE),
NAME VARCHAR2(500 BYTE),
LOGVALUE VARCHAR2(4000 BYTE),
SID NUMBER(14) NOT NULL,
PREVALUE VARCHAR2(4000 BYTE),
CHANGETIME DATE
)
而
INSERT INTO T_ETYLOGFIELD (LOGID, NAME, LOGVALUE, PREVALUE, CHANGETIME) VALUES (:B5 , :B4 , :B3 , :B2 , :B1 )
这样一个sql居然可以有超过32768个version_count,然后引发ora-600
trace file:
LIBRARY OBJECT HANDLE: handle=2ecfcca8
name=INSERT INTO T_ETYLOGFIELD (LOGID, NAME, LOGVALUE, PREVALUE, CHANGETIME) VALUES (:B5, :B4, :B3, :B2, :B1)
.........
LIBRARY OBJECT: object=2ec6f18c
type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
CHILDREN: size=32768
............
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [17059], [0x2EC6F18C], [], [], [], [], [], []
在metalink上找了好久,发现几个关于version_count 的bug,其中一个证实在9i中还未解决:
Bug 4297280 OERI[17059] can occur if over 32767 schemas reference an object
Workaround:
Flush the shared pool
这个bug里的reference就是上面trace file里那个sql出现了多过32768个child
这里的child就是指因为bind mismatch而造成了oracle寻找相同sql重用执行计划时找到的许多相同的sql却不能重用,
而且我一直以为一个varchar2(4000)变量的坎不止你说的那4个 1 , 32,128,2000
但是看了你给TOMKYTE的文章
却有迷惑了
如果真是你们说的那样
那我给的这个sql是如何能突破32768个version_cout呢?
那个sql里的5个变量 2个是varchar2(4000)
一个是varchar2(500) 一个是varchar2(50)
就算是4*4*3*2也是96个啊
请高人解答我的疑惑!