thanks for the link.

Thanks. Are you sure that 11.2.0.1 results are different from 11.2.0.2? I see exectly the same behavior in 11.2.0.2/3.
Can you post complete spool file of the test: https://www.dropbox.com/s/w1892c9b6woi0g1/oica_iot.sql

   OICA   OIC_0  OIC_10  OIC_20  OIC_30  OIC_40  OIC_50  OIC_60  OIC_70  OIC_80  OIC_90 OIC_100
------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- -------
    100   30582     255     226     198     170     142     113      85      57      29       1
     90   27524     230     203     178     153     128     102      77      51      26       1
     80   24466     204     181     158     136     114      90      68      46      23       1
     70   21407     179     158     139     119      99      79      60      40      20       1
     60   18349     153     136     119     102      85      68      51      34      17       1
     50   15291     128     113      99      85      71      57      43      29      15       1
     40   12233     102      90      79      68      57      45      34      23      12       1
     30    9175      77      68      59      51      43      34      26      17       9       1
     20    6116      51      45      40      34      28      23      17      11       6       1
     10    3058      26      23      20      17      14      11       9       6       3       1
      0       1       1       1       1       1       1       1       1       1       1       1

Maybe, they did so for compatibility with previous versions. Also as we can gather stats on ordinary tables in maintenance period or on a small loads(except gtt), but for fixed objects would be better do it on usual load, so perhaps a calling same procedures but with different parameters and a calling different procedures do not differ greatly

you can check how Statspack captures this information on the higher snapshot levels, but I have a feeling it doesn’t capture predicates as well.

If you really need predicates section, try to reproduce the plan with EXPLAIN PLAN, outline and binds sections of the plan from AWR.

The bug should be fixed in 12c and I think they ought to include it in 11.2.0.4 (I hope so).

– Is there any alternative to get this details?

set serveroutput off
col uq_id new_value uq_id
select to_char(sysdate, 'YYYYMMDDHH24MISS') uq_id from dual;

select /*+ &uq_id */ count(*) from dual;

select sharable_mem, typecheck_mem
  from v$sql 
 where sql_id = (select s.prev_sql_id from v$session s where sid = userenv('sid'))
   and child_number = (select s.prev_child_number from v$session s where sid = userenv('sid'));

explain plan for select /*+ &uq_id */ count(*) from dual;

col prev_sql_id new_value sql_id
col prev_child_number new_value child_number

select s.prev_sql_id, prev_child_number from v$session s where sid = userenv('sid');

select sharable_mem, typecheck_mem
  from v$sql 
 where sql_id = '&sql_id'
   and child_number = &child_number;

SQL> @tc\xplan_shared_mem

UQ_ID
--------------
20130117072128


            COUNT(*)
--------------------
                   1


        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               15624                    0


Explained.


PREV_SQL_ID      PREV_CHILD_NUMBER
------------- --------------------
65mhg515qht3d                    0


        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               36905                96600

SQL> /

        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               36905                96600

SQL> /

        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               36905                96600

thanks for stopping by!
Yes, indeed TYPECHECK_MEM shows missing 90K+ of memory. It’s nice to know that it is accounted somehow, although not very conveniently I must say.
Another thing that I’ve noticed when I run modified script – if I re-check TYPECHECK_MEM after some inactivity time, it goes to zero (this looks promising – probably the TYPECHECK part is abandoned quickly), but also SHARABLE_MEM increases a bit from 36K to 56K:

        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               15624                    0


Explained.


        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               36905                96600

SQL> /

        SHARABLE_MEM        TYPECHECK_MEM
-------------------- --------------------
               56418                    0