Autotrace explain plan

Hi
i like to know how can i understand the output of the autotrace ..
my current sql explain plan is
Execution Plan
Plan hash value: 2038802176
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 9 | 1026 | 332 (3)| 00:00:04 |
| 1 | SORT ORDER BY | | 9 | 1026 | 332 (3)| 00:00:04 |
| 2 | HASH UNIQUE | | 9 | 1026 | 331 (3)| 00:00:04 |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 9 | 1026 | 330 (2)| 00:00:04 |
|* 5 | TABLE ACCESS FULL | EATTEND_STUDENT_ATTENDANCE | 9 | 144 | 294 (3)|
|* 6 | INDEX RANGE SCAN | PERF_EATTEND_STUDENT_INFO_N99 | 7 | | 2 (0)| 0
|* 7 | TABLE ACCESS BY INDEX ROWID| EATTEND_STUDENT_INFO | 1 | 98 | 4 (0)| 0
how will i decide where is the performance issue ???
thanks

Don't think you have any issues here, given the small number of rows you're query returns.
You can find useful information regariding interpreting execution plans by exploring these links:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i16971
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:111012348061
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:231814117467
and do some searches on those sites yourself
Also, post your execution plan between the {noformat}{noformat} tag, so it'll stay formatted.
For example, when you type:
{noformat}select *
from dual{noformat}
it will appear as:select *
from dualwhen you post it on this forum.

Similar Messages

Explain Plan Diff not available yet on Mac ?

Hi,
I followed the Online tutorial for the new Explain Plan Diff feature, however when I right-click the tab of the auto-trace no menu appears at all.
Am I doing something wrong or is this feature not yet available on the Mac version or has it been forgotten ?
I have this version:
Oracle SQL Developer 3.0.02
Version 3.0.02
Build MAIN-02.83
Copyright © 2005,2010 Oracle. All Rights Reserved.
IDE Version: 11.1.1.4.37.58.80
Product ID: oracle.sqldeveloper
Product Version: 11.1.2.02.83
jdk 1.6.0_22
thanks, Arjan

Although I don't have a native Mac or Linux environment to test this, the context menus for the various worksheet tabs (Query Results / Autotrace / Explain Plan) have problems. I tried the following using a fresh install of SQL Dev 3.0 EA2 (including JRE 1.6.0_11):
1) VNC between two Windows XP boxes. Context menus work fine.
2) VNC (RealVNC 4.1.3 or TightVNC 2.0.2 clients) from Windows XP to Linux (Xvnc 4.0). Context menus do not appear.
3) Tarantella (Sun Secure Global Desktop Native Client [4.31.953]) from Windows XP to Linux. Context menus do not appear.
Finally, I tried the SQL Dev 2.1.1.64.65 on the OTN Developer Days image (OEL 5) under Sun Virtual Box on my XP box. No context menus.

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!

Reg:Tkprof, awr, explain plan, autotrace analysis

hi friends.
can any one give description about below subject..........
Tkprof,
awr,
explain plan,
autotrace analysis
if possible kindly mentioned some example for each OR provide some to read.
regards,
Rajnish

They're all described in the Oracle Documentation, example:
http://www.oracle.com/pls/db112/search?remark=quick_search&word=AWR&partno=
Look in the [Performance Tuning Guide|http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm] for examples/exaplanations.
Randolf Geist sums it all up very nice here: http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
More examples can be found on http://asktom.oracle.com
and on this forum by simply doing a search.

How to set autotrace to explain plan ONLY

Hi,
I would like to see explain plan for a long running statement.
Now if I do following:
set autotrace on explain
UPDATE ......-- my statement
I get the plan, but the rows are updated also :-(
Is there a way to tell ORACLE, please show me the explain plan but dio not execute the statement?
Thanks

ONLY FOR queries you can use
set autotrace traceonly explain
And actually query isn't executed. For other DML you cannot use that.
The other way can be explaining the query and then selecting the plan_table output:
SQL> explain plan for update t set code = 3;
Explained.
SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 931696821
| Id | Operation          | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |      |     3 |     9 |     3   (0)| 00:00:01 |
|   1 | UPDATE            | T    |       |       |            |          |
|   2 |   TABLE ACCESS FULL| T    |     3 |     9 |     3   (0)| 00:00:01 |
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement
13 rows selected.
SQL> see http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_xplan.htm
Gints Plivna
http://www.gplivna.eu

Saving/exporting autotrace and explain plan

Is it at all possible to export or save the explain plan and/or autotrace information from Oracle SQL Developer to text?

You must first click Explain icon or Autotrace Icon to generate them before you can check under the tab.

Autotrace and explain plan just show a green dot

When I click on the AUTOTRACE and the EXPLAIN PLAN tabs in SQL Developer all I get is a green dot. I do have PLUSTRCE roll defined to my signon. I am running SQL DEVELOPER 1.5.1 on Windows XP Professional Patch 3.

You must first click Explain icon or Autotrace Icon to generate them before you can check under the tab.

How to improve the query performance or tune query from Explain Plan

Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
     8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
          5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
               2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
                    1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
                    3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
          7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
               6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
     10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
          12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
               11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
          14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
               13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
     21 FILTER
          16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
          20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
               18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
                    17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
     23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
          42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
               38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
                    34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
                         30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
                              26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                   25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                        24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                              29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                   28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                        27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                         33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                              32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                                   31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
                    37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
                         36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
                              35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
               41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
                    40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
                         39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
          44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
               43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
          1 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        243 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
       SID
       310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
     VALUE
       163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID        CHILD_NUMBER
04mpgrzhsv72w            0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like   (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
PM:     PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
          REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
            : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Explain Plan in SQL Developer vs. SQLPlus

Hi everyone,
I've got a quick question. Why would an explain plan hang in SQL Developer but come back immediately in SQL Plus?
For example, in SQL developer, I write my statement and use the F6 command to bring up the explain plan and it just hangs and hangs. It looks like it's trying to generate an explain plan, but it's been running for hours now.
When I log into SQL Plus, I do a
SQL> explain plan for <query>:
SQL> select * from table(dbms_xplan.display);That whole process takes less than a minute to get the explain plan.
Is there something fundamentally different being executed by SQL Developer?
Thanks!
-Joe

Joe,
F6 in SQL Developer runs an AutoTrace, which actually runs the SQL and also displays timings and the explain plan. If you only want the explain plan, use F10.
Regards,
Bob

[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

Time column of an explain plan

Hi,
I'm using Oracle version 10.2.0.3.0. I have 2 tables with 10 million records each. The DDL is as follows.
create table bigtable(col1 varchar2(20), col2 varchar2(20))
create table bigtablechild(col1 varchar2(20), col2 varchar(20))
bigtablechild.col1 is a foreign key to bigtable.col1. Below is the query and explain plan. Over several executions, the query runs for about 20 seconds before returning results. Could anyone please explain what the time column represents? It doesn't match the time it took to return results.
SQL> set autotrace on
SQL>
SQL> select b.col2
2 from bigtable a, bigtablechild b
3 where a.col1 = b.col1
4 and a.col1 = 'ABC6554';
COL2
XYZ6554
XYZ6554
XYZ6554
XYZ6554
XYZ6554
Execution Plan
Plan hash value: 4210396901
| Id | Operation          | Name          | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |               |     5 |   150 | 21538   (4)| 00:04:19 |
|* 1 | HASH JOIN         |               |     5 |   150 | 21538   (4)| 00:04:19 |
|* 2 |   TABLE ACCESS FULL| BIGTABLE      |     1 |    10 | 13124   (4)| 00:02:38 |
|* 3 |   TABLE ACCESS FULL| BIGTABLECHILD |     5 |   100 | 8413   (5)| 00:01:41 |
Predicate Information (identified by operation id):
   1 - access("A"."COL1"="B"."COL1")
   2 - filter("A"."COL1"='ABC6554')
   3 - filter("B"."COL1"='ABC6554')
Statistics
          0 recursive calls
          0 db block gets
      93672 consistent gets
      91845 physical reads
          0 redo size
        463 bytes sent via SQL*Net to client
        396 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          5 rows processed

Hi,
the values in the TIME column are calculated from cost using system I/O statistics. If dbms_stats.gather_system_stats has never been run, then these stats have default values which may be very far from the truth. In your case, the optimizer expects a single-block I/O read to take about 12 ms, while in reality it is closer to 1 ms, thus the discrepancy between the prediction and actual results.
In general, TIME column is not very helpful not just because of potentially incorrect I/O time estimates, but also because it is hard to predict how much data will be found in cash, so I would recommend not to pay too much attention to it (note, however, that A-time column, on the other hand, is extremely useful, but it's only available if rowsource statistics for the plan have been populated).
Best regards,
Nikolay

Explain plan different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

Explain Plan vs. V$SQL_PLAN

Hello everyone,
I'm trying to understand the difference between those two, I'm relying on the following Tom Kyte article :
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
In my following example I didn't use TKPROF as he did but AUTOTRACE / V$SQL_PLAN instead (since EXPLAIN PLAN shows a theoretical plan that can be used if this statement were to be executed and V$SQL_PLAN contains the actual plan used)
That's my code :
>
HR> ALTER SYSTEM FLUSH shared_pool ;
HR>
HR> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
HR>
HR> create index t_idx on test(id);
Index created.
HR>
HR> -- AUTOTRACE vs V$SQL round 1 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 30 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> SET AUTOTRACE OFF
HR>
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
>
Ok so in round 1, the optimizer decided to get the 1 row back using Index Range Scan both in "theory" and in "reality", it make sense.
Now its time for round 2 ... :)
>
HR> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
HR>
HR> commit ;
Commit complete.
HR>
HR>
HR> -- AUTOTRACE vs V$SQL round 2 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
1 I_VIEWTRCOL1
1001 rows selected.
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 30030 | 6 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1001 | 30030 | 6 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1001 | | 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
HR>
>
since explain plan is using always Hard Parse (and it used dynamic sampling) I would expect to see FTS in "theory"
can anyone explain me why in round 2 they both presented Index Range Scan.
Thanks ! :)

Explain plan can lie, autotrace - which just does an explain plan - can lie.
See:
http://oracle-randolf.blogspot.com/2012/01/autotrace-polluting-shared-pool.html
http://kerryosborne.oracle-guy.com/2010/02/autotrace-lies/
http://hoopercharles.wordpress.com/2010/01/11/explain-plan-lies-autotrace-lies-tkprof-lies-what-is-the-plan/
V$SQL_PLAN is the truth.
You didn't mention version but DBMS_XPLAN is the most convenient way to get your plan.
If the plan is cached, inserting 1000 rows is not going to change the plan.
SQL> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
SQL>
SQL> create index t_idx on test(id);
Index created.
SQL>
SQL> select id, object_name from test where id = 1;
        ID OBJECT_NAME
         1 ORA$BASE
SQL>
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST |     1 |    30 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
SQL> commit;
Commit complete.
SQL> select id, object_name from test where id = 1;
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST |     1 |    30 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("ID"=1)
Note
   - dynamic sampling used for this statement (level=4)
23 rows selected.
SQL>

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 using v$sql_plan

Hi can I get explain plan by using v$sql_plan. I was trying to do:
select e.first_name, e.last_name, d.department_name from employees e
left join departments d on e.department_id=d.department_id;
select * from(select sql_id, hash_value from v$sql where sql_text = 'select e.first_name, e.last_name, d.department_name from employees e
left join departments d on e.department_id=d.department_id' order by last_load_time desc)where rownum=1
this select return me 0 records :(
so i cant do this :(
select operation, object_owner, object_name, object_type,options, cost, cardinality, bytes, cpu_cost, io_cost, depth from v$sql_plan where SQL_ID='value1' and HASH_VALUE='value2'
I dont know what am I doing wrong

bcm@bcm-laptop:~$ sqlplus hr/hr
SQL*Plus: Release 11.2.0.1.0 Production on Tue Jul 31 11:02:04 2012
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
11:02:05 SQL> set autotrace trace explain
11:02:23 SQL> select e.first_name, e.last_name, d.department_name from employees e
left join departments d on e.department_id=d.department_id;
11:02:38   2
Execution Plan
Plan hash value: 2296652067
| Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| Time
|
|   0 | SELECT STATEMENT   |           |   107 | 3638 |     7 (15)| 00:00:01
|
|* 1 | HASH JOIN OUTER   |           |   107 | 3638 |     7 (15)| 00:00:01
|
|   2 |   TABLE ACCESS FULL| EMPLOYEES      |   107 | 1926 |     3   (0)| 00:00:01
|
|   3 |   TABLE ACCESS FULL| DEPARTMENTS |    27 |   432 |     3   (0)| 00:00:01
|
Predicate Information (identified by operation id):
   1 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID"(+))
11:02:39 SQL>

Autotrace explain plan

Similar Messages

Maybe you are looking for