没有必胜的秘籍，没有方程式遵循~~ 要赢~~只有全身心的投入！

晶晶实验二十一：一个简单4031例子的引申:

上一篇 / 下一篇 2008-03-26 07:51:47 / 个人分类：晶晶oracle实验系列

查看( 880 ) / 评论( 32 )

一个简单4031例子的引申:

内存，像来是兵家必争之地。内存，像来也是一个注定要多事的地方。内存的管理，稍有不甚，即会内存泄露。就算不泄露，如果应用大量占用内存而不释放，再大也嫌少的内存将会迅速告磬。在Oracle中，常用的内存组件中，最容易出问题的，就是共享池了。共享池内存不足后，会报出一个ORA-04031错误，下面就处理这个错误方面的问题，说一下简单的例子，请ITPUB中的坛友补充。

开发人员说在测试环境中，有一个应用运行后不久就会报出4031错误，因为是9.2.0.1的系统，我设置了如下参数：
alter system set events '4031 trace name errorstack level 3';

又运行一遍应用。果然，运行不久后，又报出了4031错误，查看DUMP文件，报出错误的语句是：

select id from t3 where myid=XXXX

并且，在DUMP文件中发现大量select COL from TABLE where COL=1、select COL from TABLE where COL=2，直到COL=XXXX的语句，至此，这例4031错误已经真相大白，开发人员没有使用绑定变量，并且打开的游标没有关闭。打开源代码看了一下，果然有一段循环不停的打开游标、执行查询，好，错误的原因到此，水落石出。开发人员说，一开始先报了一个01000，超出游标数，他将open_cursor设为6000后，就报出了4031错误。

这是一个非常简单的例子，下面我来模拟一下：
步1：修改打开游标数：
alter system set open_cursors=5000;

步2：跟踪错误堆栈：
alter system set events '4031 trace name errorstack level 3';

步3：执行下如下
declare
msql varchar2(500);
mcur number;
mstat number;
jg varchar2(4000);
begin
  for i in 1..2000 loop
   mcur:=dbms_sql.open_cursor;
   msql:='select id from t3 where myid='||to_char(i);
   dbms_sql.parse(mcur,msql,dbms_sql.native);
   dbms_sql.define_column(mcur,1,jg,4000);
   mstat:=dbms_sql.execute(mcur);
end loop;
dbms_sql.close_cursor(mcur);
end;
/

第 1 行出现错误:
ORA-04031: 无法分配 1272 字节的共享内存 ("shared pool"，"select id from t3 where myid..."，"Typecheck heap"，"kkotp : kkoiqd")
ORA-06512: 在"SYS.DBMS_SYS_SQL", line 826
ORA-06512: 在"SYS.DBMS_SQL", line 32
ORA-06512: 在line 12

步4：查看跟踪文件：
在跟踪文件的开始，有如下内容：
ksedmp: internal or fatal error
ORA-04031: 无法分配 1272 字节的共享内存 ("shared pool"，"select id from t3 where myid..."，"Typecheck heap"，"kkotp : kkoiqd")
Current SQL statement for this session:
select id from t3 where myid=944

这已经显示出来了引发错误的语句：select id from t3 where myid=944 ，再向下查看，可以发现大量的select id from t3 where myid=XXX语句。

下面，再深入的想一下，如果上面的匿名过程并不是执行到将共享池内存占尽才被迫终止，而是执行多少次后，不关闭游标正常终止，在此会话退出前，游标在共享池中的部分内存，将不会被释放。而此时共享池自由内存已经被占用的差不多了，有其他的编写正确的过程、SQL语句执行时，由于无法取得足够的共享池内存，将会报出4031错误。此时，虽然我们可以看到引发4031错误的语句，但此语句并不是造成错误的真正原因，原凶另有其人。对于这样的情况，该如何找到真正的原凶呢？比如说，将上面的匿名过程改为：
declare
msql varchar2(500);
mcur number;
mstat number;
jg varchar2(4000);
begin
                     --上面例子中，循环执行到944次被中断，这次我将循环次数改为850,
  for i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。
   mcur:=dbms_sql.open_cursor;
   msql:='select id from t3 where myid='||to_char(i);
   dbms_sql.parse(mcur,msql,dbms_sql.native);
   dbms_sql.define_column(mcur,1,jg,4000);
   mstat:=dbms_sql.execute(mcur);
end loop;
dbms_sql.close_cursor(mcur);
end;
/

上面的过程可以正常执行完毕（如果在测试中仍会报出4031，可以将循环次数再缩小一些），这时，共享池的自由内存应该已经不多了。另开一些会话，随便运行一些消耗共享池的语句，不一会，4031出现了：
ksedmp: internal or fatal error
ORA-04031: 无法分配 4088 字节的共享内存 ("shared pool"，"STATSPACK"，"PL/SQL MPCODE"，"BAMIMA: Bam Buffer")
Current SQL statement for this session:
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;  broken BOOLEAN := FALSE; BEGIN statspack.snap; :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END;

引发4031的语句是STATSPACK，但，真正的原凶不是它。
好了，下面我用一个脚本，试验一下该如何定位问题的原凶。

步1：准备基本的记录共享池状态的表：
create table jj_ksmsp as select * from x$ksmsp where 0=1;
alter table jj_ksmsp add(id number);
create table jj_sqlarea as select * from v$sqlarea where 0=1;
alter table jj_sqlarea add(id number);

var id number;
exec :id:=1;

步2：
建立一个脚本 my_shared_stat.sql：

insert into jj_ksmsp select x$ksmsp.*,:id from x$ksmsp;
insert into jj_sqlarea select v$sqlarea.*,:id from v$sqlarea;
exec :id:=:id+1
commit;

步3：在于步1同一会话中，每隔一段时间运行此脚本my_shared_stat.sql

步4：随便的在其他会话中做些操作

步5：在任一会话中，运行如下匿名过程：
declare
msql varchar2(500);
mcur number;
mstat number;
jg varchar2(4000);
begin
                     --上面例子中，循环执行到944次被中断，这次我将循环次数改为850,
  for i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。
   mcur:=dbms_sql.open_cursor;
   msql:='select id from t3 where myid='||to_char(i);
   dbms_sql.parse(mcur,msql,dbms_sql.native);
   dbms_sql.define_column(mcur,1,jg,4000);
   mstat:=dbms_sql.execute(mcur);
end loop;
dbms_sql.close_cursor(mcur);
end;
/
在此步骤中，循环的次数要根据自己共享池的大小而定，目的是既要让此过程消耗共享池内存，又不至于用尽共享池内存。

步6：继续随便的在其他会话中做些操作，看什么时候会出现4031错误，
我是在执行Statspack抓取快照时，出现的4031。
sid=16 pid=15> exec statspack.snap
BEGIN statspack.snap; END;

*
第 1 行出现错误:
ORA-04031: 无法分配 2196 字节的共享内存 ("shared pool"，"STATS$SNAPSHOT"，"KGLS heap"，"KGLS MEM BLOCK")
ORA-06512: 在"PERFSTAT.STATSPACK", line 1361
ORA-06512: 在"PERFSTAT.STATSPACK", line 2442
ORA-06512: 在"PERFSTAT.STATSPACK", line 91
ORA-06512: 在line 1

select sharable_mem,persistent_mem,runtime_mem, executions  ,substr(sql_text,1,60) from (select * from jj_sqlarea order by sharable_mem desc) where rownum<=30 and id=&id;

步7：分析原因：
建立如下脚本，名为show_ksmsp.sql:
select ksmchcom, decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K',3,'3-4K',
4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,
'8-9k', 9,'9-10k','> 10K') "size",
count(*),ksmchcls Status, sum(ksmchsiz) Bytes
from jj_ksmsp
where KSMCHCOM = 'free memory' and id=&id
group by ksmchidx, ksmchcls,
'sga heap('||KSMCHIDX||',0)',ksmchcom, ksmchcls,decode(round(ksmchsiz/1000),0,'0-1K',
1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,
'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K');

依次运行：
idle> @show_ksmsp
输入 id 的值:  1

KSMCHCOM       size COUNT(*) STATUS       BYTES
---------------- ----- ---------- -------- ----------
free memory    0-1K       90 free          5088
free memory    1-2K          1 free          1324
free memory    > 10K       2 free       6318988
id为1时的资料，Free memory大于10K的Chunk有两个，共6M多字节。

idle> @show_ksmsp
输入 id 的值:  2
原值 6:  where KSMCHCOM = 'free memory' and id=&id
新值 6:  where KSMCHCOM = 'free memory' and id=2
KSMCHCOM       size COUNT(*) STATUS       BYTES
---------------- ----- ---------- -------- ----------
free memory    0-1K       106 free          5972
free memory    3-4K          1 free          2988
free memory    > 10K       2 free       5730568
id为2时的资料，Free memory大于10K的Chunk有两个，共5M多字节。

idle> @show_ksmsp
输入 id 的值:  3
KSMCHCOM       size COUNT(*) STATUS       BYTES
---------------- ----- ---------- -------- ----------
free memory    0-1K       527 free       26348
free memory    2-3K          2 free          4052
free memory    3-4K          1 free          3408
free memory    4-5K          1 free          3556
free memory    > 10K       1 free       17052
id为3时的资料，Free memory大于10K的Chunk只剩1个，也就是17K左右。1K之下的Chunk则有527个。这时，已经开始有碎片了。

idle> @show_ksmsp
输入 id 的值:  4
KSMCHCOM       size COUNT(*) STATUS       BYTES
---------------- ----- ---------- -------- ----------
free memory    0-1K       524 free       26256
free memory    1-2K       11 free          6568
free memory    > 10K       5 R-free    429700
id为4时的资料，Free memory大于10K的Chunk已经没有了，只剩下0-1K、和1-2K。

好了，不用再看下去了，问题应该是发生在ID为3或4时。在JJ_SQLAREA中查看ID为3的行：
步8：查找原凶：
先显示ID为3时，前10条占用内存最多SQL声明：
select  VERSION_COUNT,PARSE_CALLS,executions , MEM,
round(mem/(select sum(sharable_mem+persistent_mem+runtime_mem) from jj_sqlarea
  where id=3)*100,2) "Mem%", substr(sql_text,1,150)
from (select jj_sqlarea.*,sharable_mem+persistent_mem+runtime_mem MEM from jj_sqlarea
  order by mem desc)  where rownum<=&sl and id=3;
输入 sl 的值:  10

VERSION_COUNT PARSE_CALLS EXECUTIONS       MEM    Mem% SUBSTR(SQL_TEXT,1,150)
------------- ----------- ---------- ---------- ---------- --------------------------------------------------------
         1          3       2    91318    1.07 insert into jj_sqlarea select v$sqlarea.*,:id from v$sql
         1          1       1    82958       .98 select 'sid='||a.sid||' pid='||b.pid SID from v$session
         1          1       1    51594       .61 select OPEN_MODE from v$database
         3          5       30    47967       .56 select value$ from sys.props$ where name = :1
         1          1       1    42644       .5 select tc.type#,tc.intcol#,tc.position#,c.type#, c.lengt
         2       12       41    41439       .49 select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i
         1          3       3    35620       .42 insert into jj_ksmsp select x$ksmsp.*,:id from x$ksmsp
         1          1       1    31049       .37 select baseobject,type#,update$,insert$,delete$,refnewna
         1          1       1    28772       .34 select o.owner#,o.obj#,decode(o.linkname,null, decode(u.
         2       12       40    27017       .32 select ts#,file#,block#,nvl(bobj#,0),nvl(tab#,0),intcols已选择10行。

ID为3时，占用内存最多的SQL声明，是我自己的向JJ_SQLAREA中收集数据的脚本，它也只不过占用了所有SQL声明内存总量的1.07%。再看下面的这些SQL，并不能发现什么异常，扩大显示范围，显示前100条：
VERSION_COUNT PARSE_CALLS EXECUTIONS       MEM    Mem% SUBSTR(SQL_TEXT,1,150)
------------- ----------- ---------- ---------- ---------- ------------------------------------------
                  （省略部分内容...............）
         1          1       1    8930       .11 select id from t3 where myid=433
         1          1       1    8930       .11 select id from t3 where myid=547
         1          1       1    8930       .11 select id from t3 where myid=604
         1          1       1    8930       .11 select id from t3 where myid=661
         1          1       1    8930       .11 select id from t3 where myid=490
         1          1       1    8886       .1 select id from t3 where myid=554
         1          1       1    8862       .1 select id from t3 where myid=403
         1          1       1    8862       .1 select id from t3 where myid=480
         1          1       1    8862       .1 select id from t3 where myid=475
         1          1       1    8862       .1 select id from t3 where myid=470
         1          1       1    8862       .1 select id from t3 where myid=465
         1          1       1    8862       .1 select id from t3 where myid=460
                  （省略部分内容...............）

发现大量硬解析，好了，原凶终于浮出水面。

总结一下，此处，查看某条语句是否占用过多的共享池内存，或是否有大量相似的SQL语句，是找到问题的一般途径。
很多时候，“原凶”可能是Oracle的Bug。因此，如果真出现了4031，还要对引发共享池内存泄露的BUG有所了解。
还有一些4031，是不可再现的，重启数据库后，再也没有出现过。这种情况最是让人揪心，好像你的数据库中有了一颗定时炸弹。

对于可再现的4031，我上面的例子中脚本，只是一个非常简单的例子，真的要想找出原凶，还可以收集更多的视图中的资料，将收集资料的脚本my_shared_stat.sql，设为一个定时执行的自动任务。当然也可以使用STATSPACK，不过STATSPACK收集的资料过多，有些对4031是没用的，我觉得如果要想让收集频率更高一些的话，可以自己设计脚本，有针对性的收集一些视图的资料。这样收集资料的脚本需要做的工作更少，完成的速度更快，收集的频率也可以更高。

上面例子中，我的脚本只是测试用的，因此，统计的信息并不全面，在出现4031时，还应该关注的视图有
V$SHARED_POOL_RESERVED
v$sgastat
V$SQL_SHARED_MEMORY
x$kghlu
x$ksmlru
v$resource_limit

可以用于4031的跟踪事件还有：
alter system set events '4031 trace name heapdump level 2';
alter system set events 'immediate trace name library_cache level 11';

对于可重现的4031，使用statspack在比较大的时间粒度下，持续的收集资料，找出引发4031出现的时段，在再相应的时段中，用自己的脚本，以比较高的频率（比较细的时间粒度）收集有针对性的资料，对于发现错误的原凶，也很有帮助。另外，对你所使用的数据库版本4031方面的BUG要有所了解，很多4031问题，都是由BUG引发的。

[ 本帖最后由晶晶小妹于 2008-3-26 07:55 编辑 ]

全部脚印 不留脚印留下脚印:

论坛模式推荐收藏分享给好友推荐到圈子管理

TAG:

jimhou 发布于2008-03-26 08:27:55: 顶

dhs0227 发布于2008-03-26 08:39:03: 頂

bluemoon0083发布于2008-03-26 08:48:07: 不错顶一下

yuxuan 发布于2008-03-26 09:00:15: 很详细，学习

vepeta发布于2008-03-26 09:15:34: 学习！

mustapha 发布于2008-03-26 09:22:18: 分析的很清晰，支持

fikong2005 发布于2008-03-26 09:37:11: 先顶再看

rollingpig 发布于2008-03-26 09:38:12: hehe
(W~O'k0Lq;z`#Nz|space.itpub.net这个procedure ,当年我写过，就是为了向开发说明 shared_pool再大，也不能开太大的open cursors. 当然，为了速度我只parse 而不执行。
t M3Br#Uespace.itpub.net[php]&m!wW,mY:@&cW
@
for i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。ITPUB个人空间M$DU#A:DX:J;i1H
   mcur:=dbms_sql.open_cursor;ITPUB个人空间#b`4t:W!~0A8B)ja
   msql:='select id from t3 where myid='||to_char(i);  ITPUB个人空间"yaG8a_G0z!g7k
   dbms_sql.parse(mcur,msql,dbms_sql.native);
end loop;
3qTbW'O
?d dbms_sql.close_cursor(mcur);
XQeh?space.itpub.netend;
y)bc7[ie`sGITPUB个人空间..,Rr6]+r3nGi
.(v0u!Y6l*[
[/php]5X6xWzU
yZ-f:]
N){
另外，找元凶的更好方法是看 v$open_cursor+V$sqlArea group by SIDITPUB个人空间+NyK.RVg`
[php]$n|9MY;DK*x K{
select /*+ordered use_hash(c s) no_merge(s) no_merge(c) */
mGQoD4]v$`U;qL3_#Iisid,sum(sharable_mem)/1024/1024 from I#o7t_5d~;M.y_
v$open_cursor c , v$sqlarea s
where c.hash_value =s.hash_valueq}0\0w\
group by c.sid
Nd,u^`WbTt2akorder by 2 descITPUB个人空间_(@APl5i0j7?
...ITPUB个人空间;~B
Cru P
...
[/php]
space.itpub.netX]AOT'@
立刻就可以找出占用大量share pool memory的SID%Oi-Dyoo.w]
然后需要的话再select * from v$open_cursor where sid = .. 看到具体语句
*I7iF"N(@8i"bITPUB个人空间u[5s,eNPQ
[ 本帖最后由 rollingpig 于 2008-3-26 09:40 编辑 ]

Alienovo 发布于2008-03-26 09:47:50: 不错学习一下

wangfans 发布于2008-03-26 10:00:02: 学习

jieyancai发布于2008-03-26 10:04:26: 透过现象看本质，强！

五“宅”一生发布于2008-03-26 10:39:56: 学习，支持晶晶！

paulyibinyi 发布于2008-03-26 11:26:45: 不错

john_77发布于2008-03-26 11:29:22: 学习了

cyt2005发布于2008-03-26 11:44:27: QUOTE:
原帖由 rollingpig 于 2008-3-26 09:38 发表
8N:wI:x&LIR.Bhehe
"sm0x}*p!d7_r_这个procedure ,当年我写过，就是为了向开发说明 shared_pool再大，也不能开太大的open cursors. 当然，为了速度我只parse 而不执行。
`[TA2XR'z#k$^[php]space.itpub.net^|Ujo$Um
for i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。ITPUB个人空间i0l7H.j5B#GoE
   mcur:=dbms_sql.open_cursor;
iP\?1E5n0fspace.itpub.net    msql:='select id from t3 where myid='||to_char(i);
   dbms_sql.parse(mcur,msql,dbms_sql.native);
end loop;ITPUB个人空间5O#dT$B'[$WR
dbms_sql.close_cursor(mcur);
$u'DS~i*Tend;
)L;N]3D1mf
m6w..
ZB-vT$Q7R
l3kjITPUB个人空间.VR%He-L5b1W
[/php]
另外，找元凶的更好方法是看 v$open_cursor+V$sqlArea group by SID
1p9@8~TF g[php]space.itpub.netmL*ff(W8X)y,cqeD
select /*+ordered use_hash(c s) no_merge(s) no_merge(c) */s:qu m8Bs O
sid,sum(sharable_mem)/1024/1024 from ITPUB个人空间
c8S(zG
X
j
^
v$open_cursor c , v$sqlarea sITPUB个人空间I&x-kE
`XL
where c.hash_value =s.hash_valueHzz"Ga6O~
group by c.sidITPUB个人空间'l!t3VC.s(k3PL#o+WK
order by 2 desc&P*N2xZ,@){:E
...
...
_N_%oLyITPUB个人空间[/php]
aS
VS"}1[Aspace.itpub.netITPUB个人空间n6ytS
xe
立刻就可以找出占用大量share pool memory的SID
Asj#Qq.A5dITPUB个人空间然后需要的话再select * from v$open_cursor where sid = .. 看到具体语句
ITPUB个人空间~RI
N0]K-p5E5^
space.itpub.net|RRe(KZN`

'AW2F'sjI5G'i
斑竹使问题由繁入简

feng_xin 发布于2008-03-26 11:48:22

QUOTE:

原帖由 rollingpig 于 2008-3-26 09:38 发表
H?+^^
{.G7j8ehehe RXv1Do*L8^!Y
这个procedure ,当年我写过，就是为了向开发说明 shared_pool再大，也不能开太大的open cursors. 当然，为了速度我只parse 而不执行。O+v ~v[g-q
[php]
:f6^Zm}/k{g&Mfor i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。`E#_]#y&H}]
   mcur:=dbms_sql.open_cursor;
   msql:='select id from t3 where myid='||to_char(i);
*pl[pX    dbms_sql.parse(mcur,msql,dbms_sql.native);
1w%iYQf1i_(Uz end loop;
R:@X6uy};n@n3gd dbms_sql.close_cursor(mcur);
/Z{hv1SITPUB个人空间end;
..
6N)\
i:y9zspace.itpub.net.
[/php]Fz&F&G+jz7\
另外，找元凶的更好方法是看 v$open_cursor+V$sqlArea group by SIDspace.itpub.netDIj!VO1E3D2a
[php]ITPUB个人空间]ab
Bw"h0i?8P9P
select /*+ordered use_hash(c s) no_merge(s) no_merge(c) */
[(Cz'H2Msid,sum(sharable_mem)/1024/1024 from Pr ~@7ZB
v$open_cursor c , v$sqlarea s
7jK!BU'k QK{where c.hash_value =s.hash_value
group by c.sid
order by 2 descspace.itpub.net_wC`8@
...S4cT1p+H3\%c\ N
...
!z-he4x.}UA[/php]
AC&K:Jf#u9UNITPUB个人空间space.itpub.netSGOp?&i
DOd
立刻就可以找出占用大量share pool memory的SID
然后需要的话再select * from v$open_cursor where sid = .. 看到具体语句

4031的错误大部分是未绑定变量SQL语句引起的。排除bug后，就要从v$sqlarea与v$open_cursor中找出元凶sql语句。

元凶有两种：
1，未绑定变量并且大量执行的sql, 这种sql就是晶晶模拟出来的现象。可以通过如下SQL语句抓出来。
先找出sql:

CODE:

select count(*), sum(sharable_mem),substr(sql_text,50) from v$sqlarea group by substr(sql_text,50) order by 1,2;substr取的字符的个数，根据应用进行调整。

然后根据找出的SQL确定是哪个应用执行的

CODE:

select sid,sharable_mem,s.sql_text from v$open_cursor c , v$sqlarea s where c.hash_value =s.hash_value and s.sql_text like 'xxxxxxxx%'

2，单条SQL需要大量内存空间，如果内存里有空间但是是由很多小空间碎片组成的话，当执行这个占用内存大的单条sql时，由于不能分配空间，而产生4031错误。这种sql一般来说都是够长够复杂的sql. 可以通过如下SQL语句抓出来。
先找出sql

CODE:

select sid,s.sharable_mem,s.sql_text,s.ADDRESS,s.HASH_VALUE from v$open_cursor c , v$sqlarea s where c.hash_value =s.hash_value order by sharable_mem;

通常sql_text不能把sql显示完整，用如下查询找出完整的sql.

CODE:

select a.address,a.hash_value,a.piece,a.sql_text,a.command_type from v$sqltext a,

(select sid,s.sharable_mem,s.sql_text,s.ADDRESS,s.HASH_VALUE from v$open_cursor c , v$sqlarea s where c.hash_value =s.hash_value and s.sharable_mem>xxxxx) b

where a.address=b.address and a.hash_value=b.hash_value

order by 1,2,3;

guyuanli发布于2008-03-26 11:53:04: 学习了,支持晶晶!

qsxing发布于2008-03-26 12:16:42: 学习了....

isongshu发布于2008-03-26 12:31:21: 学习一下

jiangjh62发布于2008-03-26 13:39:09: 3Q ,很不错

晶晶小妹发布于2008-03-26 18:19:21: QUOTE:
原帖由 rollingpig 于 2008-3-26 09:38 发表
}9?Im*LITPUB个人空间hehe
xORX&DI;U这个procedure ,当年我写过，就是为了向开发说明 shared_pool再大，也不能开太大的open cursors. 当然，为了速度我只parse 而不执行。
0Y3t;]@[[php]
for i in 1..850 loop --即可以消耗大量内存，又不会报出4031错误。ITPUB个人空间/^@5NxR3n:o#]1b
   mcur:=dbms_sql.open_cursor;space.itpub.net~&a?fn'a`U
   msql:='select id from t3 where myid='||to_char(i);    Y} ?p"F#W:ul
   dbms_sql.parse(mcur,msql,dbms_sql.native);space.itpub.net3XLJ`xcj~
end loop;space.itpub.net4d*r+b TClt
dbms_sql.close_cursor(mcur);"El` X:Nn3ww(v
end;ITPUB个人空间9d?bFW _
..space.itpub.netk/OP$L6m~w*o1r
.2G
`5SGs-S!TS
[/php]
E8Q|[Z0g(X另外，找元凶的更好方法是看 v$open_cursor+V$sqlArea group by SIDITPUB个人空间L^YO\7I&e
[php]
k0W(En/P,r#q)Rselect /*+ordered use_hash(c s) no_merge(s) no_merge(c) */0@)l:HCYRNfWx
sid,sum(sharable_mem)/1024/1024 from
)cN9{Liv$open_cursor c , v$sqlarea sITPUB个人空间s5[6T:o/j
where c.hash_value =s.hash_value
bpP2lF2V:]
U~space.itpub.netgroup by c.sidspace.itpub.netU]j6l#wx)y!Z
WS
order by 2 descL
D*KgO4P;S
...
!~
p,J\_8uIIrN...
lP1Ykce
[/php]
Mi,Jg0Vd4Q
yW"xf8hyuo
yspace.itpub.net立刻就可以找出占用大量share pool memory的SIDLak6{/K0G9D:K
然后需要的话再select * from v$open_cursor where sid = .. 看到具体语句

A n^3Z7X:j7yITPUB个人空间3nN xbr

i5I3pY-ST!SPM2W老大补充的好，大家还有什么好意见补充一下，我写个专门“抓元凶”的脚本，也方便一下初学者。