Toad explain plan

Hi,
I understand that reading output of an explain starts from the mostly indented lines.
Anyhow in TOAD (I am using version 9.7) toad Adds a number before each line in the explain plan tree. This number looks random to me because I cannot link it to the execution plan as per indentation.
Can anybody tell me what this number before each line is ?
Thanks
AK

askanaan wrote:
I understand that reading output of an explain starts from the mostly indented lines.
...Though this may "sometimes" be so, it is certainly not a general rule. It all depends on the (parent) operations that preceed/follow that "mostly indented line".
Here's a simple counter-example using the emp/dept tables.
  1  explain plan for
  2  select d.deptno
  3        ,d.dname
  4        ,(select count(*)
  5          from emp e
  6          where e.deptno=d.deptno) as count_emp
  7* from dept d
SQL> /
Explained.
SQL> @vp
More...
PLAN_TABLE_OUTPUT
Plan hash value: 4111639169
| Id  | Operation          | Name | Rows  | Bytes |
|   0 | SELECT STATEMENT   |      |     1 |    22 |
|   1 |  SORT AGGREGATE    |      |     1 |    13 |
|*  2 |   TABLE ACCESS FULL| EMP  |     1 |    13 |
|   3 |  TABLE ACCESS FULL | DEPT |     1 |    22 |
Predicate Information (identified by operation id):
   2 - filter("E"."DEPTNO"=:B1)This plan starts at line 3. Not 2, which is the "mostly indented line".
Here's another one:
  1  explain plan for
  2  select d.*
  3  from emp e
  4      ,(select d1.deptno
  5        from dept d1
  6        where d1.loc in (select d2.loc
  7                         from dept d2
  8                         group by d2.loc
  9                         having count(*) > 1)) d
10* where e.deptno = d.deptno
SQL> /
Explained.
SQL> @vp
More...
PLAN_TABLE_OUTPUT
Plan hash value: 1621130288
| Id  | Operation                     | Name          |
|   0 | SELECT STATEMENT              |               |
|   1 |  NESTED LOOPS SEMI            |               |
|   2 |   NESTED LOOPS                |               |
|   3 |    TABLE ACCESS FULL          | EMP           |
|   4 |    TABLE ACCESS BY INDEX ROWID| DEPT          |
|*  5 |     INDEX UNIQUE SCAN         | SYS_C00204096 |
|*  6 |   VIEW                        | VW_NSO_1      |
|*  7 |    FILTER                     |               |
|   8 |     SORT GROUP BY             |               |
|   9 |      TABLE ACCESS FULL        | DEPT          |
Predicate Information (identified by operation id):
   5 - access("E"."DEPTNO"="D1"."DEPTNO")
   6 - filter("D1"."LOC"="$nso_col_1")
   7 - filter(COUNT(*)>1)If you think this one starts at line 9, you're wrong again. It starts at line 3.
You need to understand all the "operations" that can appear in an execution plan.
Only then can you deduce where the execution of such plan really starts.
Toon

Similar Messages

  • Able to execute a query in TOAD but can't ceate explain plan

    Hi,
    I can execute a query in TOAD which uses table from other schema. I have created the synonym and given the rights on it.
    But when I try to create explain plan using TOAD: I get Ora-00942:Table or view does not exist.
    Any suggestions..
    Thanks..

    user8941550 wrote:
    But if I just try
    Explain Plan for
    select t.xml_msg_text
    from xml_tbl t
    THen this works.That will have to be executed as a script in TOAD, which essentially shells out to use SQL*Plus and capture the output, so it's not Toads in-built explain plan.
    In another schema I can generate the plan.So that other schema has been set up with toads explain plan table.
    In TOAD look in Database -> Administer -> Server Side Objects Wizard
    and follow that through to create the necessary toad objects on the server.

  • How to enable Explain plan in TOAD

    Hi,
    I am using toad version 8.6.1.Whenever i login as my userid and run a sql stmnt i am trying to get explain plan from toad explain plan button.But it's not showing anything some times it says insuffcient privileges.I created synonym called plan_table which is based on actual plan_table.But no luck.Can you pls help me how to enable explain plan in toad
    Thanks
    Anand

    Anand,
    in earlier versions of Toad you could use the notoad.sql or toadprep.sql to create the required tables.
    In your version it is probably already has been replaced by menu option Tools->Server Side Object Wizard.
    Toad does not use the plan_table - it creates it's own set of tables including the table for the explain plan.
    Mike

  • Explain Plan in TOAD

    I am trying to use TOAD to find the query performance. When I clicked on explain plan tab i get an error message: ORA-02404: specified plan table not found.
    Can some one please tell me how to proceed from here so that I can check the explain plan for this table

    I don't know how TOAD works with EXPLAIN PLAN, but mybe it is if you have PLAN_TABLE created in your database and granted all on it to public.
    SQL> @<ORACLE_HOME>/rdbms/admin/utlxplan.sql
    SQL> create public synonym plan_table for plan_table
    SQL> grant all on plan_table to public
    I don't know if you're looking for somethinkg like that ...

  • Hi when i run this in toad for explain plan  its showing an error ORA_22905

    hi when i run this query in toad for explain plan its showing an error ORA_22905 cannot accesss rows from an non nested table item can anyone help me out
    SELECT
    DISTINCT SERVICE_TBL.SERVICE_ID , SERVICE_TBL.CON_TYPE, SERVICE_TBL.S_DESC || '(' || SERVICE_TBL.CON_TYPE || ')' AS SERVICE_DESC ,SERVICE_TBL.CON_STAT
    FROM
    TABLE(:B1 )SERVICE_TBL
    WHERE
    CON_NUM = :B2
    thanks

    Note the name of this forum is SQL Developer *(Not for general SQL/PLSQL questions)* (so for issues with the SQL Developer tool). Please post these questions under the dedicated SQL And PL/SQL forum.
    Regards,
    K.

  • Not able to use EXPLAIN PLAN in Toad

    hi,
    I am not able to use Explain Plan in Toad. The error it gives is the table PLAN_TABLE doesn't exit.
    But after seeing this error I did run the script "UTLXPLAN.sql" in order to create the plan_table table.
    After installing the above table I am not able to use EXPLAIN_PLAN from toad, Its giving same error Table PLAN_TABLE doesn't exit though i created it successfully in the proper schema.
    Thanks in advance
    Ram

    check and post.
    SQL> select owner from dba_tables where table_name='PLAN_TABLE';
    before using toad ,first u should connect to sqlplus by that user and issue
    SET AUTOTRACE ON.
    Kuljeet

  • TOAD HELP - Explain Plan

    Hi,
    I am using TOAD 8.0 for oracle 9i DB and new to toad
    I had set the plan table for a schema say schema1@dev1 as follows
    view>options>oracle>general>
    explain plan table name -> TOAD_PLAN_TABLE
    username -> xa11.....some blah blah that came by default
    When i gave ctrl+e i got the execution plan
    Now i connected as schema2@prod1 but when I try getting execution plan I get following error
    ORA-00904: "PARTITION_STOP": invalid identifier
    what should i do for this? the scema doesnt have DBA priv too.
    Thanks ,
    s

    And please stop posting the same questions in
    multiple forums.The reason is that - when a person doesn't get any proper solution he/she is keep looking for one easy solution which will solve his/her problem. As a result of that we may encounter same posting in multiple forum. I don't think it is unjustyfiable. Main reason is - somehow you need to solve the problem within schedule time. It is natural human behabiour. Though many user may disagree with me. This is completely my opinion.
    I guess the best location for such a question would
    be a TOAD forum.Indeed - if the user knows such forum. So, better give that link to this user. I hope you don't mind.
    Regards.
    Satyaki De.

  • Unable to generate explain plan from toad

    HI,
    Toad Version:8.6
    I was unable to generate the explain plan in the toad.Here i create PLAN_TOAD table also but it is still getting the same error
    ORA-00942: table or view does not exist

    Hello,
    You created the Table PLAN_TABLE but you must check the configuration of TOAD.
    It seems to me that by default TOAD use the Table TOAD_PLAN_TABLE.
    So, you must set the right name of the Table (or rename the Table PLAN_TABLE).
    Best regards,
    Jean-Valentin Lubiez

  • How can i paste the explain plan from toad..

    Hello all
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please help

    964145 wrote:
    I tried taking a snap of the explain plan from toad but in this forum the paste option is disabled...please helpI don't know, but it is a waste of time since explain plans from Toad are not useful.
    Please read the forum FAQ on providing information for a tuning request, it describes how to generate an explain plan that can be shared.
    {message:id=9360003}
    This is an example.
    SQL> explain plan for
      2  select * from dual;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3543395131
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
    --------------------------------------------------------------------------

  • Query tunning in Oracle using Explain Plan

    Adding to my below question: I have now modified the query and the path shownby 'Explain plan' has reduced. The 'Time' column of plan_table is also showing much lesser value. However, some people are suggesting me to consider the time required by the query to execute on Toad. Will it be practical? Please help!!
    Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...
    Edited by: 885901 on Sep 20, 2011 2:10 AM

    885901 wrote:
    Hi, I am using Oracle 11g. I need to optimize a Select query(Need to minimize the execution time). I need to know how 'Explain Plan' would help me. I know how to use Explain Plan command. I refer Plan_table table to see the details of the plan. Please guide me regarding which columns of the Plan_table should be considered while modifying the query for optimization. Some people say, 'Time' column should be considered, some say 'Bytes' etc. Some suggest on minimizing the full table scans, while some people say that I should minimize the total no. operations (less no. of rows should be displayed in Plan_table). As per an experienced friend of mine, full table scans should be reduced (for e.g. if there are 5 full table scans in the plan, then try to reduce them to less than 5. ). However, if I consider any full table scan operation in the plan_table, its shows value of 'time' column as only 1 which is very very less. Does this mean the full scan is actually taking very less time?? If yes, then this means full table scans are very fast in my case and no need to work on them. Some articles suggest that plan shown by 'Explain Plan' command is not necessarily followed while executing the query. So what should I look for then? How should I optimize the query and how will I come to know that it's optimized?? Please help!!...how fast is fast enough?

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

  • Same query, same dataset, same ddl setup, but wildly different explain plan

    Hello o fountains of oracle knowledge!
    We have a problem that caused us a full stop when rolling out a new version of our system to a customer and a whole Sunday to boot.
    The scenario is as follows:
    1. An previous version database schema
    2. The current version database schema
    3. A migration script to migrate the old schema to the new
    So we perform the following migration:
    1. Export the previous version database schema
    2. Import into a new schema called schema_old
    3. Create a new schema called schema_new
    4. Run migration script which creates objects, copies data, creates indexes etc etc in schema_new
    The migration runs fine in all environments (development, test and production)
    In our development and test environments performance is stellar, on the customer production server the performance is terrible.
    This using the exact same export file (from the production environment) and performing the exact same steps with the exact same migration script.
    Database version is 10.2.0.1.0 EE on all databases. OS is Microsoft Windows Server 2003 EE SP2 on all servers.
    The system is not in any sense under a heavy load (we have tested with no other load than ourselves).
    Looking at the explain plan for a query that is run frequently and does not use bind variables we see wildly different explain plans.
    The explain plan cost on our development and test servers is estimated to *7* for this query and there are no full table scans.
    On the production server the cost is *8433* and there are two full table scans of which one is on the largest table.
    We have tried to run analyse on all objects with very little effect. The plan changed very slightly, but still includes the two full table scans on the problem server and the cost is still the same.
    All tables and indexes are identical (including storage options), created from the same migration script.
    I am currently at loss for where to look? What can be causing this? I assume this could be caused by some parameter that is set on the server, but I don't know what to look for.
    I would be very grateful for any pointers.
    Thanks,
    Håkon

    Thank you for your answer.
    We collected statistics only after we determined that the production server where not behaving according to expectations.
    In this case we used TOAD and the tool within to collect statistics for all objects. We used 'Analyze' and 'Compute Statistics' options.
    I am not an expert, so sorry if this is too naive an approach.
    Here is the query:SELECT count(0)  
    FROM score_result sr, web_scorecard sc, product p
    WHERE sr.score_final_decision like 'VENT%'  
    AND sc.CREDIT_APPLICATION_ID = sr.CREDIT_APPLICATION_ID  
    AND sc.application_complete='Y'   
    AND p.product = sc.web_product   
    AND p.inactive_product = '2' ;I use this as an example, but the problem exists for virtually all queries.
    The output from the 'good' server:
    | Id  | Operation                      | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT               |                       |     1 |    39 |     7   (0)|
    |   1 |  SORT AGGREGATE                |                       |     1 |    39 |            |
    |   2 |   NESTED LOOPS                 |                       |     1 |    39 |     7   (0)|
    |   3 |    NESTED LOOPS                |                       |     1 |    30 |     6   (0)|
    |   4 |     TABLE ACCESS BY INDEX ROWID| SCORE_RESULT          |     1 |    17 |     4   (0)|
    |   5 |      INDEX RANGE SCAN          | SR_FINAL_DECISION_IDX |     1 |       |     3   (0)|
    |   6 |     TABLE ACCESS BY INDEX ROWID| WEB_SCORECARD         |     1 |    13 |     2   (0)|
    |   7 |      INDEX UNIQUE SCAN         | WEB_SCORECARD_PK      |     1 |       |     1   (0)|
    |   8 |    TABLE ACCESS BY INDEX ROWID | PRODUCT               |     1 |     9 |     1   (0)|
    |   9 |     INDEX UNIQUE SCAN          | PK_PRODUCT            |     1 |       |     0   (0)|
    ---------------------------------------------------------------------------------------------The output from the 'bad' server:
    | Id  | Operation                 | Name                  | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT          |                       |     1 |    32 |  8344   (3)|
    |   1 |  SORT AGGREGATE           |                       |     1 |    32 |            |
    |   2 |   HASH JOIN               |                       | 10887 |   340K|  8344   (3)|
    |   3 |    TABLE ACCESS FULL      | PRODUCT               |     6 |    42 |     3   (0)|
    |   4 |    HASH JOIN              |                       | 34381 |   839K|  8340   (3)|
    |   5 |     VIEW                  | index$_join$_001      | 34381 |   503K|  2193   (3)|
    |   6 |      HASH JOIN            |                       |       |       |            |
    |   7 |       INDEX RANGE SCAN    | SR_FINAL_DECISION_IDX | 34381 |   503K|   280   (3)|
    |   8 |       INDEX FAST FULL SCAN| SCORE_RESULT_PK       | 34381 |   503K|  1371   (2)|
    |   9 |     TABLE ACCESS FULL     | WEB_SCORECARD         |   489K|  4782K|  6137   (4)|
    ----------------------------------------------------------------------------------------I hope the formatting makes this readable.
    Stats (from SQL Developer), good table:NUM_ROWS     489716
    BLOCKS     27198
    AVG_ROW_LEN     312
    SAMPLE_SIZE     489716
    LAST_ANALYZED     15.12.2009
    LAST_ANALYZED_SINCE     15.12.2009Stats (from SQL Developer), bad table:
    NUM_ROWS     489716
    BLOCKS     27199
    AVG_ROW_LEN     395
    SAMPLE_SIZE     489716
    LAST_ANALYZED     17.12.2009
    LAST_ANALYZED_SINCE     17.12.2009I'm unsure what would cause the difference in average row length.
    I could obviously try to tune our sql-statements to work on the server not behaving better, but I would rather understand why they are different and make sure that we can expect similar behaviour between environments.
    Thank you again for trying to help me.
    Håkon
    Edited by: ergates on 17.des.2009 05:57
    Edited by: ergates on 17.des.2009 06:02

  • Explain Plan changed using "IN"

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

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

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

Maybe you are looking for