Comments on: Session SQL

By: Jonathan Lewis

Jonathan Lewis — Wed, 07 Mar 2012 11:02:06 +0000

Tom, If you re-read the article you'll see the statement:

"The most important one, to my mind, is the one about the execution path. When running any “got it off the Internet” SQL against the dynamic performance views, don’t forget to check the execution path and the performance threats before you use it on production"

Running your query and pulling the plan from memory, this is what I got shortly after startup on a small 11.1 system I had at hand: [sourcecode gutter="false"] SQL> select * from table(dbms_xplan.display_cursor(null,null,'allstats last')); PLAN_TABLE_OUTPUT --------------------------------------------------------- SQL_ID gcmw0ht7u5xm8, child number 0 ------------------------------------- select /*+ gather_plan_statistics */ address || ': ' || sql_text sql_text from v$sqltext where address in ( select oc.address from v$session s, v$process p, v$open_cursor oc where p.addr = s.paddr and p.spid = 2840 and s.saddr = oc.saddr ) Plan hash value: 1481537409 -------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | OMem | 1Mem | Used-Mem | -------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 115 |00:00:00.01 | | | | |* 1 | FILTER | | 1 | | 115 |00:00:00.01 | | | | |* 2 | FIXED TABLE FULL | X$KGLNA | 1 | 1 | 6487 |00:00:00.01 | | | | | 3 | NESTED LOOPS | | 931 | 1 | 31 |00:00:00.01 | | | | | 4 | MERGE JOIN CARTESIAN | | 931 | 1 | 2541 |00:00:00.01 | | | | | 5 | NESTED LOOPS | | 931 | 1 | 2541 |00:00:00.01 | | | | | 6 | MERGE JOIN CARTESIAN | | 931 | 1 | 2541 |00:00:00.01 | | | | |* 7 | FIXED TABLE FULL | X$KGLLK | 931 | 1 | 121 |00:00:00.01 | | | | | 8 | BUFFER SORT | | 121 | 100 | 2541 |00:00:00.01 | 2048 | 2048 | 2048 (0)| | 9 | FIXED TABLE FULL | X$KSLWT | 102 | 100 | 2142 |00:00:00.01 | | | | |* 10 | FIXED TABLE FIXED INDEX| X$KSLED (ind:2) | 2541 | 1 | 2541 |00:00:00.01 | | | | | 11 | BUFFER SORT | | 2541 | 1 | 2541 |00:00:00.01 | 2048 | 2048 | 2048 (0)| |* 12 | FIXED TABLE FULL | X$KSUPR | 102 | 1 | 102 |00:00:00.01 | | | | |* 13 | FIXED TABLE FIXED INDEX | X$KSUSE (ind:1) | 2541 | 1 | 31 |00:00:00.01 | | | | -------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter( IS NOT NULL) 2 - filter(("KGLOBOCT"<>0 AND "INST_ID"=USERENV('INSTANCE'))) 7 - filter(("KGLHDPAR"=:B1 AND "KGLHDNSP"=0 AND "KGLLKHDL"<>:B2 AND "INST_ID"=USERENV('INSTANCE') AND "KGLHDPAR"<>"KGLLKHDL")) 10 - filter("W"."KSLWTEVT"="E"."INDX") 12 - filter((TO_NUMBER("KSUPRPID")=2840 AND "INST_ID"=USERENV('INSTANCE') AND BITAND("KSSPAFLG",1)<>0)) 13 - filter(("S"."INST_ID"=USERENV('INSTANCE') AND BITAND("S"."KSSPAFLG",1)<>0 AND BITAND("S"."KSUSEFLG",1)<>0 AND "ADDR"="S"."KSUSEPRO" AND "S"."ADDR"="KGLLKUSE" AND "S"."INDX"="W"."KSLWTSID")) 41 rows selected. [/sourcecode] Your query converts the IN subquery to an EXISTS subquery and operates it as a filter subquery that is called (in theory) for every row in x$kglna (v$sqltext). This is not a path you would want to see on a large, busy, production system.

By: Tom Robbins

Tom Robbins — Tue, 06 Mar 2012 22:05:42 +0000

If you also want to see the open cursors, including recursive sql, you can add a select on v$open_cursor.
This query uses unix PID to find the appropriate sql:

select   address || ':  ' || sql_text sql_text
from v$sqltext
where address in
        (select  oc.address
        from    v$session        s,
                v$process        p,
                v$open_cursor    oc
        where   p.addr     = s.paddr
        and     p.spid = &&unix_pid
        and     s.saddr = oc.saddr)

By: Weather « Oracle Scratchpad

Weather « Oracle Scratchpad — Tue, 21 Feb 2012 21:24:45 +0000

[...] thought it was pretty cold in Sarajevo a couple of weeks ago, and therefore fairly mild in Minneapolis and Denver when the temperature was [...]

By: Session SQL – All Things Oracle

Session SQL – All Things Oracle — Fri, 17 Feb 2012 15:18:59 +0000

[...] can find the answer out on my blog; Oracle Scratchpad. Jonathan [...]

By: Jonathan Lewis

Jonathan Lewis — Wed, 15 Feb 2012 02:33:46 +0000

Valentin,

True on both counts.
It’s also important to remember to include the join on “instance number” when using the gv$ – I’ve seen people forget that occasionally.

By: Valentin Nikotin

Valentin Nikotin — Mon, 13 Feb 2012 20:29:37 +0000

Though it’s very expensive to use gv$, and it’ll be better to query v$ having connected to the proper node.

By: Valentin Nikotin

Valentin Nikotin — Mon, 13 Feb 2012 15:54:03 +0000

It makes sense to remeber of the using gv$ versions of views on the RAC environment.

By: Valentin Nikotin

Valentin Nikotin — Fri, 10 Feb 2012 15:29:01 +0000

Here are two more observations about the using predicate with “OR” :

1. You can not determine what it was actually – SQL_ID or PREV_SQL_ID;
2. The query will have worse plan with NL + FIXED TABLE FULL instead of FIXED TABLE FIXED INDEX;

By: Log Buffer #258, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #258, A Carnival of the Vanities for DBAs | The Pythian Blog — Fri, 10 Feb 2012 09:56:03 +0000

[...] From time to time a request for a query to “show the current SQL” for each session appears on the internet. Jonathan answers. [...]

By: Narendra

Narendra — Fri, 10 Feb 2012 09:25:34 +0000

I’ll leave it (temporarily) as an exercise to the reader to explain why this is probably a bad strategy
Is it because the query is accessing memory structures (and not tables) which are not guaranteed to be read-consistent? So a join (between v$session and v$sql) will not necessarily give correct results. I remember Tanel poder using this to his advantage when he wrote his cool session snapper toolkits.