转载自：http://space.itpub.net/?uid-13095417-action-viewspace-itemid-217984
From rollingpig
找元凶的更好方法是看 v$open_cursor+V$sqlarea group by SID
CODE:
select /*+ordered use_hash(c s) no_merge(s) no_merge(c) */
sid,sum(sharable_mem)/1024/1024 from
v$open_cursor c , v$sqlarea s
where c.hash_value =s.hash_value
group by c.sid
order by 2 desc
...
...
sid,sum(sharable_mem)/1024/1024 from
v$open_cursor c , v$sqlarea s
where c.hash_value =s.hash_value
group by c.sid
order by 2 desc
...
...
立刻就可以找出占用大量share pool memory的SID
然后需要的话再select * from v$open_cursor where sid = .. 看到具体语句
From feng_xin
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;
(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;
