Comments on: EXPLAIN PLAN shared memory

By: Timur Akhmadeev

Timur Akhmadeev — Thu, 17 Jan 2013 03:26:40 +0000

That is wrong, I checked memory of the last executed statement which is not what's needed. Here's the right version & output: [sourcecode lang="sql"] 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; [/sourcecode] [sourcecode] 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 [/sourcecode]

By: Timur Akhmadeev

Timur Akhmadeev — Thu, 17 Jan 2013 03:06:18 +0000

Hi Tanel,

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

By: What the heck is the INTERNAL_FUNCTION in execution plan predicate section? | Tanel Poder's blog: IT & Mobile for Geeks and Pros

Thu, 17 Jan 2013 00:41:22 +0000

[...] given SQL again, in a special, more instrumented way, it has more information at hand apparently (and it uses more memory too). Or it could just be that whoever wrote V$SQL_PLAN, didn’t write the piece of code for [...]

By: Tanel Poder

Tanel Poder — Thu, 17 Jan 2013 00:25:52 +0000

Timur, the typecheck memory numbers are not in SHARABLE_MEM, but in TYPECHECK_MEM column in V$SQL… see if this adds up …

By: Oracle database features wish list – 2 (V$SQL_UNSHARED_CURSOR) « Timur Akhmadeev's blog

Tue, 21 Feb 2012 09:02:13 +0000

[...] cursor plus some infrastructure overhead. I don’t know too much details but compared to a normal child cursor size of 15K, 100-ish bytes doesn’t look much to me. And the profit would be huge. To support [...]

By: Timur Akhmadeev

Timur Akhmadeev — Mon, 20 Feb 2012 12:57:28 +0000

Igor

I think there are cases when wrapping SQL in a view could help in avoiding ORA-4031, like when you use 2 different queries based on the view – I guess. I didn’t test it, so can’t say for sure.

By: Igor Usoltsev

Igor Usoltsev — Fri, 17 Feb 2012 14:30:38 +0000

Thanks Timur, but I mean your initial huge qry_text size query which got “ORA-04031: unable to allocate 235704 bytes of shared memory (“shared pool”,”select * from (…”,”Typecheck”,”qry_text : qcpisqt”)”
Will shared pool memory usage decrease if this query is wrapped into view?

For example:
SQL> select * from view_maked_from_huge_query_text;

Is this way suitable for ORA-04031 problem resolution?

By: Timur Akhmadeev

Timur Akhmadeev — Fri, 17 Feb 2012 13:39:08 +0000

Hi Igor First of all I don't see here a big issue. Yes, EXPLAIN PLAN cursors require some additional memory that looks to be huge enough compared to the statement, but that's just fine. In a normal system there is no need to run it frequently. Second, I'm not quite sure what do you mean by "simple view". In case you think that wrapping SQL in a view such as SELECT * and then explaining it could make these memory chunks disappear, then it's not true: [sourcecode lang="sql"] SQL> SQL> explain plan for select * from (select /*+ &uq_id */ count(*) from dual); Explained. SQL> SQL> select sharable_mem 2 from v$sql 3 where sql_id = (select s.prev_sql_id from v$session s where sid = userenv('sid')) 4 and child_number = (select s.prev_child_number from v$session s where sid = userenv('sid')); SHARABLE_MEM -------------------- 36961 SQL> SQL> SQL> explain plan for select null from (select /*+ &uq_id */ count(*) from dual); Explained. SQL> SQL> select sharable_mem 2 from v$sql 3 where sql_id = (select s.prev_sql_id from v$session s where sid = userenv('sid')) 4 and child_number = (select s.prev_child_number from v$session s where sid = userenv('sid')); SHARABLE_MEM -------------------- 36964 [/sourcecode]

By: Igor Usoltsev

Igor Usoltsev — Fri, 17 Feb 2012 08:07:57 +0000

Thanks Timur, very interesting post
As far as I understand the simple view usage can help to resolve problem, isn’t it?
Igor

By: Greg

Greg — Thu, 24 Nov 2011 19:09:02 +0000

Great blog. I remember similar situation with rule based optimizer where query had big inlist and plan was huge because of redundant index unix scans .
So, simple explain blew out our production till slush shared pool because of fragmentation . That was in 9.2 DB
Regards
GregG