Re: 1.7GB SHARABLE_MEM used by single SQL

From: Eagle Fan <eagle.f_at_gmail.com>
Date: Fri, 17 Jun 2011 12:05:09 +0800
Message-ID: <BANLkTikxRGXVhekA4-r6YkgC9CC9xdfD2g_at_mail.gmail.com>



Thank you Tanel.

This is very useful information. How did you resolve the problem? What caused the bind mismatch? Was it also related to 11g jdbc driver?

Most of the reasons are BIND_MISMATCH, Some of them also have BIND_LENGTH_UPGRADEABLE=Y.
  1 select BIND_MISMATCH,BIND_LENGTH_UPGRADEABLE,STATS_ROW_MISMATCH from v$sql_shared_cursor where sql_id in (select sql_id from v$sql where hash_value=2038009379)
  2* order by 1,2,3
SQL> / B B S
- - -
N N N
N Y N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N N
Y N Y
Y N Y
Y N Y
Y N Y
Y N Y
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N
Y Y N

96 rows selected.

On Fri, Jun 17, 2011 at 7:38 AM, Tanel Poder <tanel_at_tanelpoder.com> wrote:

> Looks like a bug indeed ... I've once troubleshooted something similar...
>
> Check this:
>
> Bug 10082277 - Excessive allocation in PCUR heap of "kkscsAddChildNo"
> (ORA-4031) (Doc ID 10082277.8)
>
> https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=10082277.8&h=Y
>
> Note that this bug description mentions the detailed permanent memory
> allocation breakdown (event 10235 level 65536), but think twice before
> enabling it (even if support recommends to) as there are a few hang/spin
> bugs related to setting it...
>
> --
> Tanel Poder
> http://blog.tanelpoder.com
>
>
> On Thu, Jun 16, 2011 at 6:42 PM, Eagle Fan <eagle.f_at_gmail.com> wrote:
>
>> Hi:
>>
>> Thanks for that information.
>>
>> I run that script and found that the biggest one was the parent cursor:
>>
>> SQL> _at_curheaps 2038009379 65535
>> old 20: KGLNAHSH in (&1)
>> new 20: KGLNAHSH in (2038009379)
>> old 21: and KGLOBT09 like ('&2')
>> new 21: and KGLOBT09 like ('65535')
>>
>> KGLNAHSH KGLHDPAR CHILD# KGLHDADR
>> KGLOBHD0 SIZE0 SIZE1 SIZE2 SIZE3
>> ---------- ---------------- ---------- ---------------- ----------------
>> ---------------------- -------- -------- --------
>> KGLOBHD4 SIZE4 SIZE5 KGLOBHD6 SIZE6 SIZE7
>> STATUS
>> ---------------- -------- -------- ---------------- -------- --------
>> ----------
>> 2038009379 0000000F3BC53E78 65535 0000000F3BC53E78
>> 0000000F5BF1E648 *1883443712 *0 0 0
>> 00 0 0 00 0
>> 0 1
>>
>>
>>

-- 
Eagle Fan (www.dbafan.com)

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jun 16 2011 - 23:05:09 CDT

Original text of this message