Re: 1.7GB SHARABLE_MEM used by single SQL
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: Eagle Fan <eagle.f@xxxxxxxxx>
- Date: Fri, 17 Jun 2011 15:33:44 +0300
Some cursors get created because of bind length differences - even when the
datatype is the same. But in your case, the *number* of child cursors isn't
probably the worst problem ... especially if you have a lot of bind
variables in the statement with fluctuating letngths ... and anyway - it's
your *parent* cursor which is so large - even if you flush out 90% of the
children, the parent still consumes this memory... it's some bug - memory
leak in parent cursor. Look into that bug I sent ...
--
Tanel Poder
http://blog.tanelpoder.com
On Fri, Jun 17, 2011 at 8:36 AM, Eagle Fan <eagle.f@xxxxxxxxx> wrote:
> And it doesn't have data type conversion:
>
> SQL> select * from v$sql_bind_metadata where address in (select
> CHILD_ADDRESS from v$sql_shared_cursor where ADDRESS='0000000F3BC53E78')
> 2 and (position,datatype) not in
> 3 ((26,1),
> 4 (25,2),
> 5 (24,2),
> 6 (23,2),
> 7 (22,2),
> 8 (21,1),
> 9 (20,1),
>
Other related posts: