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

Similar Messages

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 --

Explain plan for Procedures

Hi,
I know we can generate explain plan for queries using "Explain plan" statement or "Autotrace option". I would like to know how can we generate explain plan for oracle procedures.
Thanks in Advance..

Check this link very helpful info from Rob
When your query takes too long ...
There are no explain plan for procedures.
MAy be you want to do DBMS_PROFILER for procedures execution

Explain Plan for Procedure

Hi,
For getting the explain plan for a query, we use the statement
"explain plan for " + Query
Similarly, to get an explain plan for a procedure, do we have any way like
"explain plan for " + "Execute " + Procedure
How do we get an explain plan for a procedure that is executed
Thanks in Advance.

teckfreak wrote:
Hi Robert,
I am working on an utility application which will execute the procedure and show the explain plan to the user for him to analyze the explain plan and take necessary steps for optimization. I am showing the Procedure inputs to the user, allowing him to enter values and taking them and executing the procedure. I am setting the trace and extracting the explain plan for the procedure using TKPROF utility and showing it to the user.
While doing so, the trace file is stored in udump folder. I am accessing the trace file from TKPROF utility. I am able to run the TKPROF from the command prompt. But if I try automating the TKPROF command in a .NET application using Process.Start, it says "Not able to access the file.". I tried giving full permissions to Everyone and it still throws the error. Kindly guide me how to proceed.. A different approach that you might want to consider (as indicated by William):
- Flush the shared pool and use a unique MODULE description for each execution of your procedure (e.g. using DBMS_APPLICATION_INFO.SET_MODULE), e.g. using a logon trigger
- Query V$SQL for your unique MODULE description and run DBMS_XPLAN.DISPLAY_CURSOR for each corresponding child cursor found (SQL_ID + CHILD_NUMBER) in the shared pool. This plan generation could be automated using a procedure
The result of this approach corresponds to the tracing using TKPROF since it will provide the actual execution plans used at runtime rather than separate EXPLAIN PLAN results which might differ from the actual plans.
This assumes that your shared pool is sufficiently large to hold all the child cursor created by your procedure without aging them out while the procedure is running. It's probably also only applicable to an environment where not too much work is being done while running this test and the recommended flushing of the shared pool.
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/

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. :)

Explain plan/autotrace for stored procedure

Hello,
I have an stored procedure executing a select statement. I would like to use autotrace or explain plan or something to check how my select statement is executed.
So far I've only accomplished to use autotrace on statements i write in sql*plus. The problem here is that my select statement uses some user defined types (lists of numbers and dates). Also if possible I would like my application to call the procedure providing the parameters. I feel kind of lost here.
My query is something like this:
int_list list_of_numbers;
int_list2 list_of_numbers;
date_list list_of_dates;
select * from table1, table(int_list) i1, table(int_list2) i2, table(date_list) d1 where ....

No, i do not have a "close cursor" procedure, but I just leave the tracing on for now. When in production I will turn it off.
This is just a test system so I have full control over everything.
Yes, I granted execute on dbms_session and alter session to my user, because I received an error when trying to execute the stored procedure. But with dbms_support and monitor I can't even compile my stored procedure.
I granted execute on dbms_monitor to my user and the procedure compiled fine! When trying to grant execute on dbms_support sql*plus complained on not even finding that package/procedure/whatever.
Thank you for all your help!

Passing PL/SQL Procedure call to custom explain plan script

Hi,
Oracle have sent me a custom explain plan script and have asked me to pass in my problematic code through it. They use the GET command in their script to retrieve the command which is passed in as a parameter e.g:
@custom_explain_plan <my sql script>
The script has a section as follows:
get &&1 -- my script
0 explain plan set statement_id = 'APG' into plan_table for
This works for a standard SQL statement e.g. SELECT SYSDATE FROM DUAL but (and Oracle Support know this) my issue is triggered by a call to an e-Business Suite API that updates the database. This is contained within a PL/SQL block and COMMITs a few sample updates. I've not used explain plan before but I suspect it can only be used on SQL statements? I have no access to the DELETEs and INSERTs that the API triggers, so what am I supposed to do?
Am I missing something or have Oracel Support sold me a pup?
I thought I'd post here first before going back to them...
Many thanks,
Bagpuss

Sybrand,
Many thanks for the swift confirmation. I didn't think I was going mad! Already gave them a standard trace so I guess it's up to them now - my experience with Oracle Support in the last few years has been very deflating - they evidently do not read/understand much of the information they are given in an SR. Added to that, we've had patches from them with basic syntax errors! I've consistently received much more informed responses from the various OTN forums, which are much appreciated.
I may construct the DELETE and INSERT statements dynamically myself using a typical employee record to at least give them something to ponder over...
Thanks again,
Bagpuss.

*** Interpreting this explain plan ***

Hi,
Please find the explain plan for following: I dont understand why rows = 1 in step 4 and 5 of explain plan?? There are 6 rows corresponding to the condition in join that is satisfied in service def table. Still it shows 1??
explain plan for SELECT costpools.cost_pool_id, servicedef.service_name,
costpools.special_calc
FROM cost_pools costpools, service_definitions servicedef
WHERE costpools.service_def_id = servicedef.service_def_id
AND costpools.special_calc = 'Y'
ORDER BY servicedef.service_name;
PLAN_TABLE_OUTPUT
Plan hash value: 3404549211
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 6 | 270 | 15 (7)| 00:00:01 |
| 1 | SORT ORDER BY | | 6 | 270 | 15 (7)| 00:00:01 |
| 2 | NESTED LOOPS | | 6 | 270 | 14 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | COST_POOLS | 6 | 60 | 8 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS | 1 | 35 | 1 (0)| 00:00:0
|* 5 | INDEX UNIQUE SCAN | SERVICE_DEFINITIONS_PK | 1 | | 0 (0)| 00:00:01
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
18 rows selected.
regds,
s

I mean how is it executed.....there are 6 rows in the
service_def table that satisfies the join condition
right.....so the cardinlity shud be 6 instead of 1
..isnt it??That's not the way it works in an explain plan. It works as SomeoneElse said: an index unique scan as the second step inside a nested loop will retrieve 1 row (index unique scan) but 6 times (nested loop). In the plan you'll see a "1". However, if you look at the row source operation in tkprof, it will tell you how many rows were flowing through this step in total, so here it reports 6.
SQL> create table cost_pools
2 as
3   select level cost_pool_id
4        , 'Y' special_calc
5        , level service_def_id
6     from dual
7 connect by level <= 6
8 /
Tabel is aangemaakt.
SQL> create table service_definitions
2 as
3   select 'A' service_name
4        , level service_def_id
5     from dual
6 connect by level <= 10000
7 /
Tabel is aangemaakt.
SQL> alter table service_definitions add constraint service_definitions_pk primary key (service_def_id)
2 /
Tabel is gewijzigd.
SQL> exec dbms_stats.gather_table_stats(user,'cost_pools')
PL/SQL-procedure is geslaagd.
SQL> exec dbms_stats.gather_table_stats(user,'service_definitions',cascade=>true)
PL/SQL-procedure is geslaagd.
SQL> explain plan
2 for
3 SELECT costpools.cost_pool_id, servicedef.service_name,
4 costpools.special_calc
5 FROM cost_pools costpools, service_definitions servicedef
6 WHERE costpools.service_def_id = servicedef.service_def_id
7 AND costpools.special_calc = 'Y'
8 ORDER BY servicedef.service_name
9 /
Uitleg is gegeven.
SQL> select * from table(dbms_xplan.display)
2 /
PLAN_TABLE_OUTPUT
| Id | Operation                     | Name                   | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT              |                         |     6 |    78 |     5 (20)|
|   1 | SORT ORDER BY                |                         |     6 |    78 |     5 (20)|
|   2 |   NESTED LOOPS                |                         |     6 |    78 |     4   (0)|
|* 3 |    TABLE ACCESS FULL          | COST_POOLS              |     6 |    48 |     3 (34)|
|   4 |    TABLE ACCESS BY INDEX ROWID| SERVICE_DEFINITIONS     |     1 |     5 |     2 (50)|
|* 5 |     INDEX UNIQUE SCAN         | SERVICE_DEFINITIONS_PK |     1 |       |            |
Predicate Information (identified by operation id):
   3 - filter("COSTPOOLS"."SPECIAL_CALC"='Y')
   5 - access("COSTPOOLS"."SERVICE_DEF_ID"="SERVICEDEF"."SERVICE_DEF_ID")
17 rijen zijn geselecteerd.
SQL> alter session set sql_trace true
2 /
Sessie is gewijzigd.
SQL> SELECT costpools.cost_pool_id, servicedef.service_name,
2 costpools.special_calc
3 FROM cost_pools costpools, service_definitions servicedef
4 WHERE costpools.service_def_id = servicedef.service_def_id
5 AND costpools.special_calc = 'Y'
6 ORDER BY servicedef.service_name
7 /
                          COST_POOL_ID S S
                                     1 A Y
                                     2 A Y
                                     3 A Y
                                     4 A Y
                                     5 A Y
                                     6 A Y
6 rijen zijn geselecteerd.
SQL> disconnectAnd now tkprof shows you:
SELECT costpools.cost_pool_id, servicedef.service_name,
costpools.special_calc
FROM cost_pools costpools, service_definitions servicedef
WHERE costpools.service_def_id = servicedef.service_def_id
AND costpools.special_calc = 'Y'
ORDER BY servicedef.service_name
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        4      0.00       0.00          1         17          0           6
total        6      0.00       0.00          1         17          0           6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 9833
Rows     Row Source Operation
      6 SORT ORDER BY
      6   NESTED LOOPS
      6    TABLE ACCESS FULL OBJ#(2702816)
      6    TABLE ACCESS BY INDEX ROWID OBJ#(2702817)
      6     INDEX UNIQUE SCAN OBJ#(2702818) (object id 2702818)
********************************************************************************Regards,
Rob.

Performance problem: Query explain plan changes in pl/sql vs. literal args

I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.

AmandaSoosai wrote:
I have a complex query with 5+ table joins on large (million+ row) tables. In it's most simplified form, it's essentially
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between 123 and 456;
Its performance was excellent with literal arguments (1 sec per execution).
But, when I used pl/sql bind argument variables instead of 123 and 456 as literals, the explain plan changes drastically, and runs 10+ minutes.
Ex:
CREATE PROCEDURE runQuery(param1 INTEGER, param2 INTEGER){
CURSOR LT_CURSOR IS
select * from largeTable large
join anotherLargeTable anothr on (anothr.id_2 = large.pk_id)
join...(other aux tables)
where large.pk_id between param1 AND param2;
BEGIN
FOR aRecord IN LT_CURSOR
LOOP
(print timestamp...)
END LOOP;
END runQuery;
Rewriting the query 5 different ways was unfruitful. DB hints were also unfruitful in this particular case. LargeTable.pk_id was an indexed field as were all other join fields.
Solution:
Lacking other options, I wrote a literal query that concatenated the variable args. Open a cursor for the literal query.
Upside: It changed the explain plan to the only really fast option and performed at 1 second instead of 10mins.
Downside: Query not cached for future use. Perfectly fine for this query's purpose.
Other suggestions are welcome.Best wild guess based on what you've posted is a bind variable mismatch (your column is declared as a NUMBER data type and your bind variable is declared as a VARCHAR for example). Unless you have histograms on the columns in question ... which, if you're using bind variables is usually a really bad idea.
A basic illustration of my guess
http://blogs.oracle.com/optimizer/entry/how_do_i_get_sql_executed_from_an_application_to_uses_the_same_execution_plan_i_get_from_sqlplus

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.

Oracle not using its own explain plan

When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?

Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
2 /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
2 INTO
3      dt_test_bvpeek
4 SELECT
5      rownum,
6      CASE
7          WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
8              1
9          ELSE
10              MOD(rownum, 5)
11          END
12      END
13 FROM
14      dual
15 CONNECT BY
16      LEVEL <= 100000
17 /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
2 /
COUNT(*)       COL1
     80000          1
     20000          4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
2 /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = 1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 78728 |   538K|    82 (52)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 |   538K|    82 (52)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = 4
8 /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id | Operation                   | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                   | 21027 |   143K|    74 (21)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK    | 21027 |   143K|    74 (21)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | DT_TEST_BVPEEK_I1 | 21077 |       |    29 (28)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 49882 |   340K|   100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3      *
4 FROM
5      dt_test_bvpeek
6 WHERE
7      col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |                | 49882 |   340K|   100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 |   340K|   100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      *
3 FROM
4      dt_test_bvpeek
5 WHERE
6      col1 = :an_col1
7 /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '9t52uyyq67211'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      *
3 FROM
4      dt_test_bvpeek
5 WHERE
6      col1 = :an_col1
7 /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '9t52uyyq67211'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   FULL                           DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
2 /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
2      operation,
3      options,
4      object_name
5 FROM
6      v$sql_plan
7 WHERE
8      sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION                      OPTIONS                        OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS                   BY INDEX ROWID                 DT_TEST_BVPEEK1
INDEX                          RANGE SCAN                     DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David

[8i] Can someone help me on using explain plan, tkprof, etc.?

I am trying to follow the instructions at When your query takes too long ...
I am trying to figure out why a simple query takes so long.
The query is:
SELECT COUNT(*) AS tot_rows FROM my_table;It takes a good 5 minutes or so to run (best case), and the result is around 22 million (total rows).
My generic username does not (evidently) allow access to PLAN_TABLE, so I had to log on as SYSTEM to run explain plan. In SQL*Plus, I typed in:
explain plan for (SELECT COUNT(*) AS tot_rows FROM my_table);and the response was "Explained."
Isn't this supposed to give me some sort of output, or am I missing something?
Then, the next step in the post I linked is to use tkprof. I see that it says it will output a file to a path specified in a parameter. The only problem is, I don't have access to the db's server. I am working remotely, and do not have any way to remotely (or directly) access the db server. Is there any way to have the file output to my local machine, or am I just S.O.L.?

SomeoneElse used "create table as" (CTAS), wich automatically gathers the stats. You can see the differende before and after stats clearly in this example.
This is the script:
drop table ttemp;
create table ttemp (object_id number not null, owner varchar2(30), object_name varchar2(200));
alter table ttemp add constraint ttemp_pk primary key (object_id);
insert into ttemp
select object_id, owner, object_name
from dba_objects
where object_id is not null;
set autotrace on
select count(*) from ttemp;
exec dbms_stats.gather_table_stats('PROD','TTEMP');
select count(*) from ttemp;And the result:
Table dropped.
Table created.
Table altered.
46888 rows created.
COUNT(*)
     46888
1 row selected.
Execution Plan
           SELECT STATEMENT Optimizer Mode=CHOOSE
   1         SORT AGGREGATE
   2    1      TABLE ACCESS FULL PROD.TTEMP
Statistics
          1 recursive calls
          1 db block gets
        252 consistent gets
          0 physical reads
        120 redo size
          0 PX remote messages sent
          0 PX remote messages recv'd
          0 buffer is pinned count
          0 workarea memory allocated
          4 workarea executions - optimal
          1 rows processed
PL/SQL procedure successfully completed.
COUNT(*)
     46888
1 row selected.
Execution Plan
           SELECT STATEMENT Optimizer Mode=CHOOSE (Cost=4 Card=1)
   1         SORT AGGREGATE (Card=1)
   2    1      INDEX FAST FULL SCAN PROD.TTEMP_PK (Cost=4 Card=46 K)
Statistics
          1 recursive calls
          2 db block gets
        328 consistent gets
          0 physical reads
       8856 redo size
          0 PX remote messages sent
          0 PX remote messages recv'd
          0 buffer is pinned count
          0 workarea memory allocated
          4 workarea executions - optimal
          1 rows processed

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.

How to find Explain Plan for a large querry which has multiple sub querries

Hi All,
I have a Package which has many procedures and one of the procedure has a cursor which is like 2000 lines. This cursor has a main select statement which again has many select statements in it.
Now how do I do the explain plan for the main select statement?
If it can be done easier way in toad(or SQLPLUS), please tell me...

When your query takes too long ...

Explain plan inside a procedure

Similar Messages

Maybe you are looking for