Writing explain plan inside function

I tried to make a function which will explain plan for supplied SQL statement in the plan table. However I'm getting error in following line
     /* populate the plan */
     EXPLAIN PLAN
     SET STATEMENT_ID = STATEMENT_NAME
     FOR
     SQL_STATEMENT;
where SQL_STATEMENT is a variable (eg. select * from employee).
Is it possible to write in this way inside a function/procedure?

What version of Oracle are we talking about? Some where in 9+ Oracle introduced v$sql_plan and v$sql_plan_statistics which contain the actual plan for SQL that is ran. Depending on exactly the purpose of this procedure is intended to be it may be unnecessary to being with.
HTH -- Mark D Powell --

Similar Messages

Explain plan inside a procedure

I'm using execute immediate statement to process data. I would like to have additional information about explain plan for these statements, for example:
create or replace procedure p
is
v_stmt varchar2(4000) := 'select count(*) from dual where dummy = :1';
v_plan varchar2(4000);
begin
execute immediate v_stmt using 'X';
-- here I would like to retrieve into v_plan variable an explain plan used for v_stmt
end;
Is it possible to do? If so, how?
thank you

Just trace/tkprof the session that executes the process.
You'll have the execution plan and lots more of information:
ORACLE-BASE - SQL trace, 10046, trcsess and tkprof in Oracle
Oracle related stuff: Basic SQL statement performance diagnosis - HOW TO, step by step instructions

Explain plan in procedure or function

Hi
I want to know how can i do explain plan in procedure or function. Any ideas or solution how can i do that? ;/

I mean inside function ;p
When i try execute function I always get error:
ORA-14551: cannot perform a DML operation inside a query
ORA-06512: at "HR.EXPLAIN_PLAN_SQL", line 34
14551. 00000 - "cannot perform a DML operation inside a query "
*Cause: DML operation like insert, update, delete or select-for-update
cannot be performed inside a query or under a PDML slave.
*Action: Ensure that the offending DML operation is not performed or
use an autonomous transaction to perform the DML operation within
the query or PDML slave.
heh... I got this error because its pipelined function. I forget about that ;p
Sorry for my english and thx for help. :)

Will a explain plan consider a function in a select statement.

Hi gurus,
I have a question regarding explain plan.
I ran a query, which returns me explain plan with multiple CPU costs around 300K.
now i use a function, and the number of lines displayed in explain plan reduces from 12 to 8 lines.
What i dont understand is.. Is the explain plan considering the function in the select statement ?
ex.
explain plan for
select column1,
         column2,
         function(value1)
from case
where case_no = 1will a explain plan consider the functions in a select statement ?
Thank you.

What i dont understand is.. Is the explain plan considering the function in the select statement ?Maybe there are tweaks which reveal more information from the explain plan, but a straightforward way won't necessarily expose any function call:
SQL> create or replace function get_dname (i_deptno integer)
   return varchar2
as
   l_dname   dept.dname%type;
begin
   select   dname
     into   l_dname
     from   dept
    where   deptno = i_deptno;
   return l_dname;
end get_dname;
Function created.
SQL> explain plan
   for
      select   ename, deptno, get_dname (deptno) dname
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.
SQL> truncate table plan_table
Table truncated.
SQL> explain plan
   for
      select   ename, deptno
        from   emp
       where   deptno = 10
Explain complete.
SQL> select   * from table (dbms_xplan.display ())
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     5 |    45 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     5 |    45 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("DEPTNO"=10)
13 rows selected.

Explain plan on Update statement in function

All,
I have an update statement in a function and my explain plan shows:
"Optimizer"     "Cost"     "Cardinality"     "Bytes"
"UPDATE STATEMENT"     "ALL_ROWS"     "2"     "1"     "7"
"UPDATE user.<table_name>"     ""     ""     ""     ""
"INDEX(UNIQUE SCAN) <table_name>.<PK_column_cons>"     "ANALYZED"     "1"     "1"     "7"
Filtering is on index unique column, but cost is 1 what does that mean?
do i need to change my update statement in function?
Any ideas?
Regards,
~ORA

The cost is the optimizer's measure of how much effort it will take to execute the statement. For any statement the optimizer will evaluate a number of execution plans and choose the one with the lowest cost. I wouldn't worry too much about what it actually "means". However if you want to understand this subject in a lot more detail I would recommend the book Cost-Based Oracle Fundamentals by Jonathan Lewis.
For your update statement the optimizer has chosen to access a single row by the primary key index, which is probably good enough, so you should not need to change it.
The only faster way to access the data would be to use the row's ROWID directly. You would need to have fetched this explicitly in a previous SELECT statement, or you could use it implicitly with the WHERE CURRENT OF syntax for a cursor opened with FOR UPDATE.

Problems with explain plan and statement

Hi community,
I have migrated a j2ee application from DB2 to Oracle.
First some facts of our application and database instance:
We are using oracle version 10.2.0.3 and driver version 10.2.0.3. It runs with charset Unicode 3.0 UTF-8.
Our application is using Tomcat as web container and jboss as application server. We are only using prepared statements. So if I talk about statements I always mean prepared statements. Also our application is setting the defaultNChar property to true because every char and varchar field has been created as an nchar and nvarchar.
We have some jsp sites that contains lists with search forms. Everytime I enter a value to the form that returns a filled resultset, the lists are performing great. But everytime I enter a value that returns an empty resultset, the lists are 100 times slower. The jsp sites are running in the tomcat environment and submitting their statements directly to the database. The connections are pooled by dbcp. So what can cause this behaviour??
To anaylze this problem I started logging all statements and filled-in search field values and combinations that are executed by the lists described above. I also developed a standalone helper tool that reads the logged statements, executes them to the database and generates an explain plan for every statement. But now there appears a strange situation. Every statement, that performs really fast within our application, is now executed by the helper tool extremely slow. So I edited some jsp pages within our application to force an explain plan from there (tomcat env). So when I'm executing the same statement I'm getting with the exactly same code two completely different explain plans.
First the statement itself:
select LINVIN.BBASE , INVINNUM , INVINNUMALT , LINVIN.LSUPPLIERNUM , LSUPPLIERNUMEXT , LINVIN.COMPANYCODE , ACCOUNT , INVINTXT , INVINSTS , INVINTYP , INVINDAT , RECEIPTDAT , POSTED , POSTINGDATE , CHECKCOSTCENTER , WORKFLOWIDEXT , INVINREFERENCE , RESPONSIBLEPERS , INVINSUM_V , INVINSUMGROSS_V , VOUCHERNUM , HASPOSITIONS , PROCESSINSTANCEID , FCURISO_V , LSUPPLIER.AADDRLINE1 from LINVIN, LSUPPLIER where LINVIN.BBASE = LSUPPLIER.BBASE and LINVIN.LSUPPLIERNUM = LSUPPLIER.LSUPPLIERNUM and LINVIN.BBASE = ? order by LINVIN.BBASE, INVINDAT DESC
Now the explain plan from our application:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 101 | 28583 | 55 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 101 | 28583 | 55 (0)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| 25 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | LINV_INVDAT | 101 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 1 | 148 | 1 (0)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_177597 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("LINVIN"."BBASE"=:1)
filter("LINVIN"."BBASE"=:1)
5 - access("LSUPPLIER"."BBASE"=:1 AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
Now the one from the standalone tool:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 93773 | 25M| | 12898 (1)| 00:02:35 |
| 1 | SORT ORDER BY | | 93773 | 25M| 61M| 12898 (1)| 00:02:35 |
|* 2 | HASH JOIN | | 93773 | 25M| 2592K| 7185 (1)| 00:01:27 |
| 3 | TABLE ACCESS BY INDEX ROWID| LSUPPLIER | 16540 | 2390K| | 332 (0)| 00:00:04 |
|* 4 | INDEX RANGE SCAN | LSUPPLIER_HAS_BASE_FK | 16540 | | | 11 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| LINVIN | 93709 | 12M| | 6073 (1)| 00:01:13 |
|* 6 | INDEX RANGE SCAN | LINVOICE_BMDT_FK | 93709 | | | 84 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("LINVIN"."BBASE"="LSUPPLIER"."BBASE" AND "LINVIN"."LSUPPLIERNUM"="LSUPPLIER"."LSUPPLIERNUM")
4 - access("LSUPPLIER"."BBASE"=:1)
6 - access("LINVIN"."BBASE"=:1)
The size of the tables are: LINVIN - 383.692 Rows, LSUPPLIER - 115.782 Rows
As you can see the one executed from our application is much faster than the one from the helper tool. So why picks oracle a completely different explain plan for the same statement? An why is a hash join much slower than a nested loop? Because If I'm right a nested loop should only be used when the tables are pretty small..
I also tried to play with some parameters:
I set optimizer_index_caching to 100 and optimizer_index_cost_adj to 30. I also changed optimizer_mode to FIRST_ROWS_100.
I would really appreciated, if somebody can help me with this issue, because I'm really getting more and more distressed...
Thanks in advance,
Tobias
Edited by: tobiwan on Sep 3, 2008 11:49 PM
Edited by: tobiwan on Sep 3, 2008 11:50 PM
Edited by: tobiwan on Sep 4, 2008 12:01 AM
Edited by: tobiwan on Sep 4, 2008 12:02 AM
Edited by: tobiwan on Sep 4, 2008 12:04 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:06 AM
Edited by: tobiwan on Sep 4, 2008 12:07 AM

tobiwan wrote:
Hi again,
Here ist the answer:
The problem, because I got two different explain plans, was that the external tool uses the NLS sesssion parameters coming from the OS which are in my case "de/DE".
Within our application these parameters are changed to "en/US"!! So if I'm calling in my external tool the java function Locale.setDefault(new Locale("en","US")) before connecting to the database the explain plans are finally equal.That might explain why you got two different execution plan, because one plan was obviously able to avoid a SORT ORDER BY operation, whereas the second plan required to run SORT ORDER BY operation, obviously because of the different NLS_SORT settings. An index by default uses the NLS_SORT = 'binary' order whereas ORDER BY obeys the NLS_SORT setting, which probably was set to 'GERMAN' in your "external tool" case. You can check the "NLS_SESSION_PARAMETERS" view to check your current NLS_SORT setting.
For more information regarding this issue, see my blog note I've written about this some time ago:
http://oracle-randolf.blogspot.com/2008/09/getting-first-rows-of-large-sorted.html
Now let me make a guess why you observe the behaviour that it takes so long if your result set is empty:
The plan avoiding the SORT ORDER BY is able to return the first rows of the result set very quickly, but could take quite a while until all rows are processed, since it requires potentially a lot of iterations of the loop until everything has been processed. Your front end probably by default only display the first n rows of the result set and therefore works fine with this execution plan.
Now if the result set is empty, depending on your data, indexes and search criteria, Oracle has to work through all the data using the inefficient NESTED LOOP approach only to find out that no data has been found, and since your application attempts to fetch the first n records, but no records will be found, it has to wait until all data has been processed.
You can try to reproduce this by deliberately fetching all records of a query that returns data and that uses the NESTED LOOP approach... It probably takes as long as in the case when no records are found.
Note that you seem to use bind variables and 10g, therefore you might be interested that due to the "bind variable peeking" functionality you might potentially end up with "unstable" plans depending on the values "peeked" when the statement is parsed.
For more information, see this comprehensive description of the issue:
http://www.pythian.com/blogs/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Note that this changes in 11g with the introduction of the "Adaptive Cursor Sharing".
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

Hi All,
Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
SQL> conn
Enter user-name: [email protected]
Enter password:
Connected.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE    10.2.0.3.0      Production
TNS for Linux: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
--Checking the count in PO_LINES
SQL> select count(*) from po_lines;
COUNT(*)
         0
--PO_LINES is a synonym
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
OBJECT_TYPE         OWNER
SYNONYM             APPS
--The synonym is pointing to PO.PO_LINES_ALL
SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
PO_LINES                       PO                             PO_LINES_ALL
--But when counting PO.PO_LINES_ALL I am getting different result
SQL> select count(*) c from po.po_lines_all;
         C
      8828
--Explain plan of teh original query is
SQL> explain plan for
2 select
3 * from po_lines;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
|* 1 | FILTER            |              |       |       |            |
|   2 |   TABLE ACCESS FULL| PO_LINES_ALL | 8796 | 2164K|   106   (4)|
Predicate Information (identified by operation id):
   1 - filter(NULL IS NOT NULL)
--Now the object PO.PO_LINES_ALL is TABLE, not an mview.
SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
OBJECT_TYPE         OWNER
TABLE               POSeek your help in understanding what is happening here.
Thanks in Advance,
jeneesh

Next time, prefix with APPS. when you show us the explain plan:
SQL> explain plan for
2 select
3 * from apps.po_lines; -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
select *
from EMP
where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
select *
from EMP
where EMPNO <= 0
and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

Explain Plan query

I just changed the hint to pick different indexes inside the same SQL and they have significant different performance. SQL1 is much faster than SQL2 and the explain plain is very different. I found that there is some values like :Q1003, :Q1004 and :Q1005 under Object Code in the explain plan of SQL1. May I know how to interpret this?
Thanks.
Edited by: 843672 on Mar 11, 2011 3:42 AM

Welcome to the forum.
Before you even think of posting another 'question', first read:
http://tkyte.blogspot.com/2005/06/how-to-ask-questions.html
and secondly, when it comes to tuning requests, read:
When your query takes too long ...
HOW TO: Post a SQL statement tuning request - template posting
and there's also a FAQ and a SQL and PL/SQL FAQ....
http://forums.oracle.com/forums/ann.jspa?annID=1535

Explain Plan in pl/sql

Dear All.
DBMS_XPLAN.DISPLAY_CURSOR(
   sql_id        IN VARCHAR2 DEFAULT NULL,
   child_number IN NUMBER    DEFAULT NULL,
   format        IN VARCHAR2 DEFAULT 'TYPICAL');
SQL> SELECT * FROM table (
2     DBMS_XPLAN.DISPLAY_CURSOR('b7jn4mf49n569'));
PLAN_TABLE_OUTPUT
SQL_ID b7jn4mf49n569, child number 0
select o.name, u.name from obj$ o, type$ t, user$ u where o.oid$ = t.tvoid and
u.user#=o.owner# and bitand(t.properties,8388608) = 8388608 and
(sysdate-o.ctime) > 0.0007
Plan hash value: 4266358741
| Id | Operation                     | Name    | Rows | Bytes | Cost (%CPU)| T
|   0 | SELECT STATEMENT              |         |       |       |    94 (100)|
|   1 | NESTED LOOPS                 |         |     1 |    72 |    94   (2)| 0
|   2 |   NESTED LOOPS                |         |     1 |    56 |    93   (2)| 0
|* 3 |    TABLE ACCESS FULL          | OBJ$    |    71 | 2414 |    37   (3)| 0
|* 4 |    TABLE ACCESS BY INDEX ROWID| TYPE$   |     1 |    22 |     1   (0)| 0
|* 5 |     INDEX UNIQUE SCAN         | I_TYPE2 |     1 |       |     0   (0)|
|   6 |   TABLE ACCESS CLUSTER        | USER$   |     1 |    16 |     1   (0)| 0
|* 7 |    INDEX UNIQUE SCAN          | I_USER# |     1 |       |     0   (0)|
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   3 - filter(("O"."OID$" IS NOT NULL AND SYSDATE@!-"O"."CTIME">.0007))
   4 - filter(BITAND("T"."PROPERTIES",8388608)=8388608)
   5 - access("O"."OID$"="T"."TVOID")
   7 - access("U"."USER#"="O"."OWNER#")
29 rows selected
SQL> As you can see using DBMS_XPLAN.DISPLAY_CURSOR. I can display the explain plan of any query IN SQL*PLUS.
But I want to write a PL/SQL function that generating an explain plan for any query and displaying the explain plan in a htlm page
how can i do same thing in pl/sql? I need yours advice.
Thanks in advance!

Generate the plan like so:
begin
execute immediate 'explain plan for select * from dual';
end;Then you can put the dbms_xplan.display bit into a ref cursor and pass that across to the front end.
Eg:
SQL> variable rc refcursor
SQL> begin
2 execute immediate 'explain plan for select * from dual';
3 open :rc for select * from table(dbms_xplan.display);
4* end;
SQL> /
PL/SQL procedure successfully completed.
SQL> print rc;
PLAN_TABLE_OUTPUT
Plan hash value: 3543395131
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2 |     5   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| DUAL |     1 |     2 |     5   (0)| 00:00:01 |
8 rows selected.

Explain Plan changed using "IN"

Hi ,
I am using one of the query as below
select a.x, b.y, c.z from a,b,c
where
a.x in ( select x from temp where col=b.y)
i checked explain plan this query is going to access full table x
i have index on x for temp table.
i need to check b.y in subquery as parameter and that subquery result i have to use as first main query's where criteria.
using function i can get only one record at time.
if anyone have any idea how to solve.
TIA

when i use = instead of "IN" below is the explain plan from TOAD
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=RULE
SORT UNIQUE
CONCATENATION
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES
INDEX UNIQUE SCAN     PK_JOT
TABLE ACCESS BY INDEX ROWID     BULK_BOL
INDEX RANGE SCAN     BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID     BULK_SKID
INDEX RANGE SCAN     BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES
INDEX UNIQUE SCAN     PK_JOT
TABLE ACCESS BY INDEX ROWID     BULK_BOL
INDEX RANGE SCAN     BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID     BULK_SKID
INDEX RANGE SCAN     BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES
INDEX UNIQUE SCAN     PK_JOT
TABLE ACCESS BY INDEX ROWID     BULK_BOL
INDEX RANGE SCAN     BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID     BULK_SKID
INDEX RANGE SCAN     BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID     BULK_BOL
INDEX RANGE SCAN     BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID     BULK_SKID
INDEX RANGE SCAN     BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK
TABLE ACCESS BY INDEX ROWID     JOB_DETAIL_LINES
INDEX UNIQUE SCAN     PK_JOT
when i use "IN" below is the explain plan from TOAD
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=RULE
SORT UNIQUE
FILTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL     JOB_DETAIL_LINES
TABLE ACCESS BY INDEX ROWID     BULK_BOL
INDEX RANGE SCAN     BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID     BULK_SKID
INDEX RANGE SCAN     BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN     DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID     DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN     DVD_DISC_PRINT_SUPPLY_PK
INDEX UNIQUE SCAN     PK_JOT

"Explain Plan" in Oracle SQL Developer is greyed out

Hi all,
I know this is not the right place to post this, but I have look around and do not know where to post question about Oracle SQL Developer - I presume this tool is also discussed here in this forum.
My question is very simple (I presume):
1. I installed Oracle SQL Developer 3.0.04.
2. I added a new DB connection to a DB hosted in one of my servers in the LAN.
3. However, when I am writing some SQL queries, I intend to use the "Explain Plan" feature, but it is being greyed out (disabled).
4. How can I enable it back?

Hello,
{forum:id=260}
Regards
Marcus

DECODE is changing the explain plan

I have a statement with a decode function in the where clause like this:
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)When I a pass -1 as parameter for cropgroup the filter would result in "AND '-1' = '-1' and the statement is executed in less than 2 seconds. When I leave out this where clause it takes almost 18 seconds. The result is the same so I don't understand why the explain plan is so much different and why not using index scans in the statement without decode.
Below the explain plans and tkprofs for 1 (without decode) and 2 (with decode).
*explain 1*
{code}
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
| 0 | SELECT STATEMENT | | 7080 | 2413K| | 43611 (2)|
| 1 | SORT ORDER BY | | 7080 | 2413K| 5224K| 43611 (2)|
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN | | 7156 | 2438K| | 43075 (2)|
| 4 | TABLE ACCESS FULL | DWH_ABS_DETERMINATION | 17745 | 363K| | 83 (0)|
|* 5 | HASH JOIN OUTER | | 7156 | 2292K| | 42991 (2)|
|* 6 | HASH JOIN | | 7156 | 1355K| | 42907 (2)|
|* 7 | HASH JOIN | | 6987 | 1187K| | 19170 (2)|
|* 8 | HASH JOIN | | 6947 | 963K| | 10376 (1)|
|* 9 | TABLE ACCESS BY INDEX ROWID | ALIQUOT | 3 | 144 | | 3 (0)|
| 10 | NESTED LOOPS | | 6907 | 897K| | 8577 (1)|
|* 11 | HASH JOIN | | 2264 | 187K| | 1782 (2)|
| 12 | TABLE ACCESS BY INDEX ROWID | SAMPLE | 190 | 4370 | | 17 (0)|
| 13 | NESTED LOOPS | | 2264 | 152K| | 107 (1)|
| 14 | NESTED LOOPS | | 12 | 552 | | 25 (0)|
|* 15 | TABLE ACCESS FULL | SDG_USER | 12 | 288 | | 13 (0)|
| 16 | TABLE ACCESS BY INDEX ROWID| SDG | 1 | 22 | | 1 (0)|
|* 17 | INDEX UNIQUE SCAN | PK_SDG | 1 | | | 0 (0)|
|* 18 | INDEX RANGE SCAN | FK_SAMPLE_SDG | 597 | | | 2 (0)|
| 19 | TABLE ACCESS FULL | SAMPLE_USER | 1078K| 16M| | 1669 (1)|
|* 20 | INDEX RANGE SCAN | FK_ALIQUOT_SAMPLE | 3 | | | 2 (0)|
| 21 | TABLE ACCESS FULL | ALIQUOT_USER | 3403K| 29M| | 1781 (3)|
| 22 | TABLE ACCESS FULL | TEST | 3423K| 104M| | 8775 (2)|
|* 23 | TABLE ACCESS FULL | RESULT | 3435K| 65M| | 23718 (2)|
| 24 | VIEW | PLATE | 21787 | 2851K| | 84 (2)|
|* 25 | FILTER | | | | | |
| 26 | TABLE ACCESS FULL | PLATE | 21787 | 574K| | 84 (2)|
|* 27 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 28 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 29 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 30 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
|* 31 | INDEX UNIQUE SCAN | PK_OPERATOR_GROUP | 1 | 7 | | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID" IS NULL
OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
"OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+
*/ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND
"GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
3 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
5 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
6 - access("TEST_ID"="TEST_ID")
7 - access("ALIQUOT_ID"="ALIQUOT_ID")
8 - access("ALIQUOT_ID"="ALIQUOT_ID")
9 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
11 - access("SAMPLE_ID"="SAMPLE_ID")
15 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
"U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR))
17 - access("SDG_ID"="SDG_ID")
18 - access("SDG_ID"="SDG_ID")
20 - access("SAMPLE_ID"="SAMPLE_ID")
23 - filter("NAME"='End result')
25 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
"OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
27 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
28 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
30 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
- 'PLAN_TABLE' is old version
{code}
*tkprof 1*
{code}
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:21:47 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT sdu.u_crop_group,
sd.name as sdg_name,
ad.variety_name,
ad.batch_number,
a.name as aliquot_name,
sau.u_box_code as box_code,
sau.u_box_position as box_position,
t.name as test_name,
r.original_result,
plt.name as plate_name,
concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
lims_sys.sdg_user sdu,
lims_sys.sample sa,
lims_sys.sample_user sau,
lims_sys.aliquot a,
lims_sys.aliquot_user au,
lims_sys.test t,
lims_sys.result r,
lims_sys.plate plt,
lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
--AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 1.15 1.16 0 0 0 0
Fetch 1 8.53 16.10 227649 241266 0 500
total 3 9.68 17.27 227649 241266 0 500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
500 SORT ORDER BY (cr=241266 pr=227649 pw=0 time=16104631 us)
21311 FILTER (cr=241266 pr=227649 pw=0 time=16246749 us)
21311 HASH JOIN (cr=241266 pr=227649 pw=0 time=16225434 us)
17745 TABLE ACCESS FULL DWH_ABS_DETERMINATION (cr=374 pr=0 pw=0 time=69 us)
21311 HASH JOIN RIGHT OUTER (cr=240892 pr=227649 pw=0 time=16170607 us)
21895 VIEW PLATE (cr=316 pr=0 pw=0 time=43825 us)
21895 FILTER (cr=316 pr=0 pw=0 time=43823 us)
21895 TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=31 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311 HASH JOIN (cr=240576 pr=227649 pw=0 time=16106174 us)
21311 HASH JOIN (cr=133559 pr=121596 pw=0 time=9594130 us)
21311 HASH JOIN (cr=94323 pr=83281 pw=0 time=6917067 us)
21311 HASH JOIN (cr=86383 pr=75547 pw=0 time=5509672 us)
7776 HASH JOIN (cr=8134 pr=0 pw=0 time=285364 us)
7776 TABLE ACCESS BY INDEX ROWID SAMPLE (cr=572 pr=0 pw=0 time=27152 us)
7876 NESTED LOOPS (cr=377 pr=0 pw=0 time=488287 us)
99 HASH JOIN (cr=160 pr=0 pw=0 time=4168 us)
99 TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1209 us)
5719 TABLE ACCESS FULL SDG (cr=107 pr=0 pw=0 time=17 us)
7776 INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=623 us)(object id 45990)
1079741 TABLE ACCESS FULL SAMPLE_USER (cr=7562 pr=0 pw=0 time=24 us)
3307948 TABLE ACCESS FULL ALIQUOT (cr=78249 pr=75547 pw=0 time=3331129 us)
3406836 TABLE ACCESS FULL ALIQUOT_USER (cr=7940 pr=7734 pw=0 time=556 us)
3406832 TABLE ACCESS FULL TEST (cr=39236 pr=38315 pw=0 time=3413192 us)
3406832 TABLE ACCESS FULL RESULT (cr=107017 pr=106053 pw=0 time=6848487 us)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
0 INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
total 3 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows Row Source Operation
1 FAST DUAL (cr=0 pr=0 pw=0 time=3 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.00 0.00 0 0 0 0
Execute 3 1.15 1.16 0 0 0 1
Fetch 2 8.53 16.10 227649 241266 0 501
total 8 9.68 17.27 227649 241266 0 502
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 30 0.00 0.00 0 0 0 0
Execute 30 0.00 0.00 0 0 0 0
Fetch 30 0.00 0.00 0 40 0 10
total 90 0.00 0.00 0 40 0 10
Misses in library cache during parse: 0
3 user SQL statements in session.
30 internal SQL statements in session.
33 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_880.trc
Trace file compatibility: 10.01.00
Sort options: default
8 sessions in tracefile.
3 user SQL statements in trace file.
30 internal SQL statements in trace file.
33 SQL statements in trace file.
6 unique SQL statements in trace file.
633 lines in trace file.
23 elapsed seconds in trace file.
{code}

explain 2
SQL Statement which produced this data:
select * from table(dbms_xplan.display)
PLAN_TABLE_OUTPUT
| Id | Operation                               | Name                     | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                        |                          |    71 | 24779 |   857   (1)|
|   1 | SORT ORDER BY                          |                          |    71 | 24779 |   857   (1)|
|* 2 |   FILTER                                |                          |       |       |            |
|* 3 |    TABLE ACCESS BY INDEX ROWID          | RESULT                   |     1 |    20 |     4   (0)|
|   4 |     NESTED LOOPS                        |                          |    72 | 25128 |   856   (1)|
|   5 |      NESTED LOOPS                       |                          |    70 | 23030 |   576   (1)|
|* 6 |       HASH JOIN OUTER                   |                          |    69 | 20493 |   369   (1)|
|   7 |        NESTED LOOPS                     |                          |    69 | 11247 |   285   (0)|
|   8 |         NESTED LOOPS                    |                          |    69 | 10626 |   147   (0)|
|   9 |          NESTED LOOPS                   |                          |    23 | 2438 |    78   (0)|
| 10 |           NESTED LOOPS                  |                          |    23 | 2070 |    32   (0)|
| 11 |            NESTED LOOPS                 |                          |     1 |    67 |    15   (0)|
| 12 |             NESTED LOOPS                |                          |     1 |    45 |    14   (0)|
|* 13 |              TABLE ACCESS FULL          | SDG_USER                 |     1 |    24 |    13   (0)|
| 14 |              TABLE ACCESS BY INDEX ROWID| DWH_ABS_DETERMINATION    |     1 |    21 |     1   (0)|
|* 15 |               INDEX UNIQUE SCAN         | PK_DWH_ABS_DETERMINATION |     1 |       |     0   (0)|
| 16 |             TABLE ACCESS BY INDEX ROWID | SDG                      |     1 |    22 |     1   (0)|
|* 17 |              INDEX UNIQUE SCAN          | PK_SDG                   |     1 |       |     0   (0)|
| 18 |            TABLE ACCESS BY INDEX ROWID | SAMPLE                   |   190 | 4370 |    17   (0)|
|* 19 |             INDEX RANGE SCAN            | FK_SAMPLE_SDG            |   597 |       |     2   (0)|
| 20 |           TABLE ACCESS BY INDEX ROWID   | SAMPLE_USER              |     1 |    16 |     2   (0)|
|* 21 |            INDEX UNIQUE SCAN            | PK_SAMPLE_USER           |     1 |       |     1   (0)|
|* 22 |          TABLE ACCESS BY INDEX ROWID    | ALIQUOT                  |     3 |   144 |     3   (0)|
|* 23 |           INDEX RANGE SCAN              | FK_ALIQUOT_SAMPLE        |     3 |       |     2   (0)|
| 24 |         TABLE ACCESS BY INDEX ROWID     | ALIQUOT_USER             |     1 |     9 |     2   (0)|
|* 25 |          INDEX UNIQUE SCAN              | PK_ALIQUOT_USER          |     1 |       |     1   (0)|
| 26 |        VIEW                             | PLATE                    | 21787 | 2851K|    84   (2)|
|* 27 |         FILTER                          |                          |       |       |            |
| 28 |          TABLE ACCESS FULL              | PLATE                    | 21787 |   574K|    84   (2)|
|* 29 |          INDEX UNIQUE SCAN              | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
| 30 |       TABLE ACCESS BY INDEX ROWID       | TEST                     |     1 |    32 |     3   (0)|
|* 31 |        INDEX RANGE SCAN                 | FK_TEST_ALIQUOT          |     1 |       |     2   (0)|
|* 32 |      INDEX RANGE SCAN                   | FK_RESULT_TEST           |     2 |       |     2   (0)|
|* 33 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 34 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 35 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
|* 36 |    INDEX UNIQUE SCAN                    | PK_OPERATOR_GROUP        |     1 |     7 |     0   (0)|
Predicate Information (identified by operation id):
   2 - filter(("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
              "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1)) AND ("GROUP_ID"
              IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B2)) AND ("GROUP_ID" IS NULL OR EXISTS
              (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B3)) AND ("GROUP_ID" IS NULL OR EXISTS
              (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP" "OPERATOR_GROUP" WHERE
              "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B4)))
   3 - filter("NAME"='End result')
   6 - access("PLT"."PLATE_ID"(+)="PLATE_ID")
13 - filter("U_ABS_DETERMINATION" IS NOT NULL AND "U_CLIENT_TYPE"='QC' AND
              "U_WEEK_OF_PROCESSING"=TO_NUMBER(:WEEK) AND "U_YEAR_OF_SAMPLE_DELIVERY"=TO_NUMBER(:YEAR) AND
              DECODE(:CROPCODE,(-1),'-1',"U_CROP_GROUP")=DECODE(:CROPCODE,(-1),'-1',:CROPCODE))
15 - access("U_ABS_DETERMINATION"="DETERMINATION_ASSIGNMENT")
17 - access("SDG_ID"="SDG_ID")
19 - access("SDG_ID"="SDG_ID")
21 - access("SAMPLE_ID"="SAMPLE_ID")
22 - filter("STATUS"='C' OR "STATUS"='P' OR "STATUS"='V')
23 - access("SAMPLE_ID"="SAMPLE_ID")
25 - access("ALIQUOT_ID"="ALIQUOT_ID")
27 - filter("GROUP_ID" IS NULL OR EXISTS (SELECT /*+ */ 0 FROM "LIMS"."OPERATOR_GROUP"
              "OPERATOR_GROUP" WHERE "OPERATOR_ID"="LIMS$OPERATOR_ID"() AND "GROUP_ID"=:B1))
29 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
31 - access("ALIQUOT_ID"="ALIQUOT_ID")
32 - access("TEST_ID"="TEST_ID")
33 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
34 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
35 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
36 - access("GROUP_ID"=:B1 AND "OPERATOR_ID"="LIMS$OPERATOR_ID"())
Note
   - 'PLAN_TABLE' is old version
tkprof 2
TKPROF: Release 10.2.0.3.0 - Production on Tue Jan 13 13:28:26 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT sdu.u_crop_group,
       sd.name as sdg_name,
       ad.variety_name,
       ad.batch_number,
       a.name as aliquot_name,
       sau.u_box_code as box_code,
       sau.u_box_position as box_position,
       t.name as test_name,
       r.original_result,
       plt.name as plate_name,
       concat(chr(a.plate_row + 64),a.plate_column) as plate_position,
       au.u_replicate_number as replicate_number
FROM lims_sys.sdg sd,
     lims_sys.sdg_user sdu,
     lims_sys.sample sa,
     lims_sys.sample_user sau,
     lims_sys.aliquot a,
     lims_sys.aliquot_user au,
     lims_sys.test t,
     lims_sys.result r,
     lims_sys.plate plt,
     lims_sys.abs_determination ad
WHERE sd.sdg_id = sdu.sdg_id
AND sd.sdg_id = sa.sdg_id
AND sa.sample_id = sau.sample_id
AND sau.sample_id = a.sample_id
AND a.aliquot_id = au.aliquot_id
AND au.aliquot_id = t.aliquot_id
AND t.test_id = r.test_id
AND plt.plate_id (+) = a.plate_id
AND sdu.u_abs_determination = ad.determination_assignment
AND a.status IN ('V','P','C')
AND r.name = 'End result'
AND sdu.u_client_type = 'QC'
AND sdu.u_year_of_sample_delivery = (:year)
AND sdu.u_week_of_processing = (:week)
AND decode(:cropcode,-1,'-1',sdu.u_crop_group) = decode(:cropcode,-1,'-1',:cropcode)
ORDER BY box_code, box_position, replicate_number
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.45       0.87          0          0          0           0
Fetch        1      1.00       0.99          0     221420          0         500
total        3      1.46       1.86          0     221420          0         500
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows     Row Source Operation
    500 SORT ORDER BY (cr=221420 pr=0 pw=0 time=992364 us)
21311   FILTER (cr=221420 pr=0 pw=0 time=1128970 us)
21311    TABLE ACCESS BY INDEX ROWID RESULT (cr=221420 pr=0 pw=0 time=1086345 us)
42623     NESTED LOOPS (cr=217549 pr=0 pw=0 time=30006317 us)
21311      NESTED LOOPS (cr=174880 pr=0 pw=0 time=809278 us)
21311       NESTED LOOPS (cr=110117 pr=0 pw=0 time=553538 us)
21311        HASH JOIN OUTER (cr=46182 pr=0 pw=0 time=319102 us)
21311         TABLE ACCESS BY INDEX ROWID ALIQUOT (cr=45866 pr=0 pw=0 time=193037 us)
29088          NESTED LOOPS (cr=39885 pr=0 pw=0 time=320084 us)
   7776           NESTED LOOPS (cr=24267 pr=0 pw=0 time=156721 us)
   7776            NESTED LOOPS (cr=937 pr=0 pw=0 time=78954 us)
     99             NESTED LOOPS (cr=454 pr=0 pw=0 time=3826 us)
     99              NESTED LOOPS (cr=253 pr=0 pw=0 time=2833 us)
     99               TABLE ACCESS FULL SDG_USER (cr=53 pr=0 pw=0 time=1531 us)
     99               TABLE ACCESS BY INDEX ROWID DWH_ABS_DETERMINATION (cr=200 pr=0 pw=0 time=956 us)
     99                INDEX UNIQUE SCAN PK_DWH_ABS_DETERMINATION (cr=101 pr=0 pw=0 time=438 us)(object id 46965)
     99              TABLE ACCESS BY INDEX ROWID SDG (cr=201 pr=0 pw=0 time=707 us)
     99               INDEX UNIQUE SCAN PK_SDG (cr=101 pr=0 pw=0 time=330 us)(object id 46071)
   7776             TABLE ACCESS BY INDEX ROWID SAMPLE (cr=483 pr=0 pw=0 time=16261 us)
   7776              INDEX RANGE SCAN FK_SAMPLE_SDG (cr=217 pr=0 pw=0 time=562 us)(object id 45990)
   7776            TABLE ACCESS BY INDEX ROWID SAMPLE_USER (cr=23330 pr=0 pw=0 time=64710 us)
   7776             INDEX UNIQUE SCAN PK_SAMPLE_USER (cr=15554 pr=0 pw=0 time=33728 us)(object id 46012)
21311           INDEX RANGE SCAN FK_ALIQUOT_SAMPLE (cr=15618 pr=0 pw=0 time=43423 us)(object id 45346)
21895         VIEW PLATE (cr=316 pr=0 pw=0 time=43833 us)
21895          FILTER (cr=316 pr=0 pw=0 time=21936 us)
21895           TABLE ACCESS FULL PLATE (cr=316 pr=0 pw=0 time=37 us)
      0           INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
21311        TABLE ACCESS BY INDEX ROWID ALIQUOT_USER (cr=63935 pr=0 pw=0 time=182479 us)
21311         INDEX UNIQUE SCAN PK_ALIQUOT_USER (cr=42624 pr=0 pw=0 time=99160 us)(object id 45386)
21311       TABLE ACCESS BY INDEX ROWID TEST (cr=64763 pr=0 pw=0 time=219096 us)
21311        INDEX RANGE SCAN FK_TEST_ALIQUOT (cr=42669 pr=0 pw=0 time=129354 us)(object id 46222)
21311      INDEX RANGE SCAN FK_RESULT_TEST (cr=42669 pr=0 pw=0 time=125893 us)(object id 45940)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
      0    INDEX UNIQUE SCAN PK_OPERATOR_GROUP (cr=0 pr=0 pw=0 time=0 us)(object id 45769)
select 'x'
from
dual
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          0          0           1
total        3      0.00       0.00          0          0          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 97
Rows     Row Source Operation
      1 FAST DUAL (cr=0 pr=0 pw=0 time=6 us)
begin :id := sys.dbms_transaction.local_transaction_id; end;
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          2           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0          0          2           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 97
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.00          0          0          2           0
Execute      3      0.45       0.87          0          0          0           1
Fetch        2      1.00       0.99          0     221420          0         501
total        8      1.46       1.87          0     221420          2         502
Misses in library cache during parse: 2
Misses in library cache during execute: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       43      0.01       0.00          0          0         12           0
Execute    128      0.00       0.01          0          0          0           0
Fetch      178      0.00       0.00          0        383          0         465
total      349      0.01       0.02          0        383         12         465
Misses in library cache during parse: 5
Misses in library cache during execute: 5
    3 user SQL statements in session.
128 internal SQL statements in session.
131 SQL statements in session.
Trace file: C:\oracle\product\10.2.0\admin\nautp02\udump\nautp02_ora_5456.trc
Trace file compatibility: 10.01.00
Sort options: default
       1 session in tracefile.
       3 user SQL statements in trace file.
     128 internal SQL statements in trace file.
     131 SQL statements in trace file.
      19 unique SQL statements in trace file.
    1352 lines in trace file.
     287 elapsed seconds in trace file.

Explain plan shows 300T of TempSpc and 999 hours - tuning request

Hi,
I have a query which obtains summary statistics. There is an items table which contains the dictionary of items which can be recorded. There is an events table which contains the item ID, timestamp and a value. The query summarizes the data for each item. e.g. Mean, stddev, sample values, length. I have trimmed the query down as simply as possible and am having a problem with large temp space and runtime estimates in the explain plan. Here is the query:
WITH ChartItems AS (
    SELECT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      COUNT(*),
      COUNT(distinct subject_id)
    FROM mimic2v26.d_chartitems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
    --WHERE ci.itemid = 51
    GROUP BY ci.itemid,
             ci.label,
             ci.category,
             ci.description
--select * from ChartItems;
, RawData AS (
    SELECT DISTINCT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
      ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
      value1_last
    FROM ChartItems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData;Which gives this explain plan:
Plan hash value: 642453121
| Id | Operation                    | Name           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |                | 4811G| 1238T|       | 3686M (13)|999:59:59 |
|   1 | VIEW                        |                | 4811G| 1238T|       | 3686M (13)|999:59:59 |
|   2 |   HASH UNIQUE                |                | 4811G|   258T|       | 3686M (13)|999:59:59 |
|   3 |    WINDOW BUFFER             |                | 4811G|   258T|       | 3686M (13)|999:59:59 |
|   4 |     SORT GROUP BY            |                | 4811G|   258T|   317T| 3686M (13)|999:59:59 |
|* 5 |      HASH JOIN               |                | 4811G|   258T| 4943M|    25M (90)| 85:14:28 |
|   6 |       VIEW                   | VW_DAG_0       |   152M| 3199M|       | 1366K (1)| 04:33:18 |
|   7 |        HASH GROUP BY         |                |   152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 8 |         HASH JOIN            |                |   152M| 4216M|       |   147K (2)| 00:29:36 |
|   9 |          TABLE ACCESS FULL   | D_CHARTITEMS   | 4832 | 96640 |       |     7   (0)| 00:00:01 |
| 10 |          INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M| 1683M|       |   147K (1)| 00:29:25 |
| 11 |       TABLE ACCESS FULL      | CHARTEVENTS    |   196M| 6922M|       |   616K (1)| 02:03:19 |
Predicate Information (identified by operation id):
   5 - access("CE"."ITEMID"="ITEM_2")300T of temp space! Ouch.
TKPROF output (I let the query run for a short while. I let it run for ages earlier, but wasn't tracing the session. Should I let it run for longer?):
TKPROF: Release 11.2.0.3.0 - Development on Tue Jul 10 16:54:27 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
WITH ChartItems AS (
    SELECT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      COUNT(*),
      COUNT(distinct subject_id)
    FROM mimic2v26.d_chartitems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
    GROUP BY ci.itemid,
             ci.label,
             ci.category,
             ci.description
, RawData AS (
    SELECT DISTINCT
      ci.itemid,
      ci.label,
      ci.category,
      ci.description,
      last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
      ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
      value1_last
    FROM ChartItems ci
    JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.02       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1    582.40     712.23     705238     737351          0           0
total        3    582.43     712.25     705238     737351          0           0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         0          0          0 VIEW (cr=0 pr=0 pw=0 time=184 us cost=3686387254 size=1361581801333882 card=4811243114254)
         0          0          0   HASH UNIQUE (cr=0 pr=0 pw=0 time=180 us cost=3686387254 size=283863343740986 card=4811243114254)
         0          0          0    WINDOW BUFFER (cr=0 pr=0 pw=0 time=74 us cost=3686387254 size=283863343740986 card=4811243114254)
         0          0          0     SORT GROUP BY (cr=0 pr=0 pw=0 time=59 us cost=3686387254 size=283863343740986 card=4811243114254)
178073889 178073889 178073889      HASH JOIN (cr=737351 pr=705238 pw=124635 time=476372451 us cost=25572251 size=283863343740986 card=4811243114254)
   6211631    6211631    6211631       VIEW VW_DAG_0 (cr=613768 pr=581413 pw=35805 time=286546567 us cost=1366486 size=3354399576 card=152472708)
   6211631    6211631    6211631        HASH GROUP BY (cr=613768 pr=581413 pw=35805 time=281271878 us cost=1366486 size=4421708532 card=152472708)
196182740 196182740 196182740         HASH JOIN (cr=613768 pr=545608 pw=0 time=557485047 us cost=147987 size=4421708532 card=152472708)
      4832       4832       4832          TABLE ACCESS FULL D_CHARTITEMS (cr=18 pr=16 pw=0 time=13666 us cost=7 size=96640 card=4832)
196182740 196182740 196182740          INDEX FAST FULL SCAN CHARTEVENTS_O2 (cr=613750 pr=545592 pw=0 time=148428499 us cost=147046 size=1765644660 card=196182740)(object id 96501)
10683044   10683044   10683044       TABLE ACCESS FULL CHARTEVENTS (cr=123583 pr=123825 pw=0 time=25175510 us cost=616507 size=7258761380 card=196182740)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
db file sequential read                         2        0.01          0.01
db file scattered read                          3        0.02          0.03
direct path read                             5265        0.75         77.13
asynch descriptor resize                        1        0.00          0.00
direct path write temp                      15077        0.71         45.54
direct path read temp                        2387        0.29         13.54
SQL*Net break/reset to client                   1        0.66          0.66
SQL*Net message from client                     1        0.00          0.00
SQL ID: 7jby2dxrpkkm9 Plan Hash: 1388734953
select SYS_CONTEXT('USERENV','SESSIONID')
from
dual
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          0          0           1
total        3      0.00       0.01          0          0          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         1          1          1 FAST DUAL (cr=0 pr=0 pw=0 time=4 us cost=2 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.02       0.04          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        2    582.40     712.23     705238     737351          0           1
total        6    582.43     712.27     705238     737351          0           1
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       4        0.00          0.00
db file sequential read                         2        0.01          0.01
db file scattered read                          3        0.02          0.03
direct path read                             5265        0.75         77.13
asynch descriptor resize                        1        0.00          0.00
direct path write temp                      15077        0.71         45.54
direct path read temp                        2387        0.29         13.54
SQL*Net break/reset to client                   1        0.66          0.66
SQL*Net message from client                     3       14.99         15.01
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
total        0      0.00       0.00          0          0          0           0
Misses in library cache during parse: 0
    2 user SQL statements in session.
    0 internal SQL statements in session.
    2 SQL statements in session.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Trace file compatibility: 11.1.0.7
Sort options: default
       1 session in tracefile.
       2 user SQL statements in trace file.
       0 internal SQL statements in trace file.
       2 SQL statements in trace file.
       2 unique SQL statements in trace file.
   24245 lines in trace file.
     728 elapsed seconds in trace file.Optimizer parameters:
NAME                                               TYPE        VALUE
optimizer_capture_sql_plan_baselines               boolean     FALSE
optimizer_dynamic_sampling                         integer     2
optimizer_features_enable                          string      11.2.0.3
optimizer_index_caching                            integer     0
optimizer_index_cost_adj                           integer     100
optimizer_mode                                     string      ALL_ROWS
optimizer_secure_view_merging                      boolean     TRUE
optimizer_use_invisible_indexes                    boolean     FALSE
optimizer_use_pending_statistics                   boolean     FALSE
optimizer_use_sql_plan_baselines                   boolean     TRUE                                                                                                 Can anyone help me figure out what's wrong?
This is a data warehouse, with up to date statistics. The DB is version 11.2.0.3.0
Thanks,
Dan

rp0428 wrote:
>
I trimmed the query down to the simplest that I could which still exhibited the problem
>
The DISTINCT isn't the issue. The issue is that the query you posted isn't necessary and doesn't appear to be represented in the plan that you posted.
That makes it hard to tell where the cardinality misestimates are coming from. How many records does the actual first query (the one with the group by) return? You have a SELECT * commented out - how many rows?No, it's not necessary, but then it isn't the full query. The estimates are still wrong when I pass the count columns through to the second query. The full query contains many more analytic functions in the second query, and some additions to the first. It could probably be cleaned up a little, but the current structure makes logical sense. Should I change the aggregates to analytics and move them into the second query? In any case, there definitely seems to be something wrong with the plan.
I don't know what you mean when you say "doesn't appear to be represented in the plan that you posted".
I just checked the first query and while the temp space has dropped to a reasonable amount, the number of rows in the hash join is still way off (I didn't notice before because I was looking at the temp space). The rows for d_chartitems and the index on chartevents are correct:
Plan hash value: 1249235674
| Id | Operation               | Name           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT        |                |   152M|    35G|       | 1366K (1)| 04:33:18 |
|   1 | VIEW                   |                |   152M|    35G|       | 1366K (1)| 04:33:18 |
|   2 |   WINDOW SORT           |                |   152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 3 |    HASH JOIN            |                |   152M| 4216M|       |   147K (2)| 00:29:36 |
|   4 |     TABLE ACCESS FULL   | D_CHARTITEMS   | 4832 | 96640 |       |     7   (0)| 00:00:01 |
|   5 |     INDEX FAST FULL SCAN| CHARTEVENTS_O2 |   196M| 1683M|       |   147K (1)| 00:29:25 |
Predicate Information (identified by operation id):
   3 - access("CE"."ITEMID"="CI"."ITEMID")Edited by: danscott on Jul 10, 2012 5:43 PM
Edited by: danscott on Jul 11, 2012 6:28 AM

SQLDeveloper can't generate an explain-plan when using "cube"

If I want to create an explain-plan from the following statement, I get no explain-plan:
SELECT 1
FROM dual
GROUP BY CUBE( 2, 2, 2, 2, 2, 2, 2, 2, 2 )If I now want to create an explain-plan again, I get the following message (and still no explain-plan):
http://i.imgur.com/mGO6Z.jpg
I tried this a few times and of course with a fresh db-session where i didn't run any statements before.
I get this with:
SQLDeveloper Version 3.0.04 Build MAIN-04.34 (i.e. production)
DB 9.2.0.1.0
Oracle Instant Client 11.1.0.6.0
In Toad this works btw.
(Of course it makes no sense to run it on this statement, we encountered this problem with a really big SQL-statement where "cube" was used in an inline-view. SQLDeveloper then wasn't able to generate an explain-plan for the whole-statement)
Regards
Markus

that is correct. I wanted to keep the login page redirect inside my class method so that I could do the check every time someone came to pages that require authentication. I wanted it in the LoadState method so I can do a check there, redirect
them to login page or just get a cookie and then pass that cookie to page to build the UI for the page
I can do what you are suggesting and have actually tried it but then I have to track which page to take the user to after they log in...
I have multiple clicks in the appbar and pages from where the user can come to these authentication-bound pages..
Suggestions?
Also, what am I doing wrong in my class method that it doesn't navigate to the login page in the LoadState method?
Thanks
mujno

Explain Plan useability

I like the explain plan functionality - it is good for doing spot checks on execution plans. Unfortunately, I cannot copy the plan once it is produced, so if I need to send someone a copy of the plan, I revert to producing the execution plan in TOAD.

Yes ..
I too feel same.
I right-click explain plan in TOAD and then paste it in excel.
It goes there row by row...Useful Feature.
--Sanjeev

Writing explain plan inside function

Similar Messages

Maybe you are looking for