Query Regarding Explain Plan on Query

Hello,
I have one big query which shows report of 50000 daily records from @ 20,00,000 records.
I have two databases UAT and PROD.when i do Explain Plan on the query is these different database i get the different plan where everything is same in both database.
In UAT it is doing Index scan where as in PROD it is doing Full TableScan. Below are the results.
In production it is not using any of the indexes present but in UAT it is.What could be the reasong behind this?

Sure.
UAT Explain Plan (Please copy in Textpad for better View)
SELECT STATEMENT, GOAL = HINT: ALL_ROWS     Cost=371     Cardinality=238     Optimizer=HINT: ALL_ROWS     Bytes=134470
VIEW     Object owner=SWNET1          Cost=371     Cardinality=238          Bytes=134470
COUNT STOPKEY                              
VIEW     Object owner=SWNET1          Cost=371     Cardinality=238          Bytes=131376
SORT ORDER BY STOPKEY          Cost=371     Cardinality=238          Bytes=54026
FILTER                              
HASH JOIN RIGHT ANTI          Cost=370     Cardinality=238          Bytes=54026
INLIST ITERATOR                              
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_END_POINT     Cost=1     Cardinality=1     Optimizer=ANALYZED     Bytes=31
INDEX RANGE SCAN          Object owner=SWNET1     Object name=IS_UK_EP_NAME     Cost=1     Cardinality=1     Optimizer=ANALYZED     
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_TRANSACTION     Cost=368     Cardinality=253     Optimizer=ANALYZED     Bytes=49588
INDEX FULL SCAN          Object owner=SWNET1     Object name=IS_IX_T_DESTINATION_EP     Cost=18     Cardinality=13909     Optimizer=ANALYZED
PRODUCTION Explain Plan
SELECT STATEMENT, GOAL = HINT: ALL_ROWS               Cost=65702     Cardinality=1000     Optimizer=HINT: ALL_ROWS     Bytes=565000
VIEW     Object owner=SWNET1          Cost=65702     Cardinality=1000          Bytes=565000
COUNT STOPKEY                              
VIEW     Object owner=SWNET1          Cost=65702     Cardinality=38739          Bytes=21383928
SORT ORDER BY STOPKEY          Cost=65702     Cardinality=38739          Bytes=9646011
FILTER                              
HASH JOIN RIGHT ANTI          Cost=63616     Cardinality=38739          Bytes=9646011
INLIST ITERATOR                              
TABLE ACCESS BY INDEX ROWID     Object owner=SWNET1     Object name=IS_TB_END_POINT     Cost=1     Cardinality=2     Optimizer=ANALYZED     Bytes=64
INDEX UNIQUE SCAN          Object owner=SWNET1     Object name=IS_UK_EP_NAME     Cost=1     Cardinality=2     Optimizer=ANALYZED     
TABLE ACCESS FULL          Object owner=SWNET1     Object name=IS_TB_TRANSACTION     Cost=63614     Cardinality=44697     Optimizer=ANALYZED     Bytes=9699249
Index Query (Same on both places)
create index IS_IX_T_DESTINATION_EP on IS_TB_TRANSACTION (T_DESTINATION_EP)
tablespace IS_XML_IND
pctfree 10
initrans 2
maxtrans 255
storage
initial 128M
next 128K
minextents 1
maxextents unlimited
pctincrease 0
);

Similar Messages

  • Query regarding Explain Plan

    Hi,
    I have a query regarding explain plan. While we gather the statistics then optimize choose the best possible plan out of the explain plans available. If we do not gather statistics on a table for a long time then which plan it choose:
    If it will continue to use the same plan as it use in the starting when statistics were gathered or will change the plan as soon as dml activities performed and statistics getting old.
    Thanks
    GK

    Hi,
    Aman.... wrote:
    Gulshan wrote:
    Hi,
    I have a query regarding explain plan. While we gather the statistics then optimize choose the best possible plan out of the explain plans available. If we do not gather statistics on a table for a long time then which plan it choose:The same plan which it has chosen in the starting with the previous statistics. The plan won't change automatically as long as you won't refresh the statistics. This is wrong even for Oracle 9i. Here are couple of examples when a plan might change with the same optimizer statistics:
    * when you have a histogram on a column and are not a bright person to use bind variables, you might get a completely different execution plan because of a different incoming value. All that is needed to fall into this habit - a soft parse, which might be due to different reasons, for instance, due to session parameter modification (which also might change a plan even without a histogram)
    * Starting with 10g, CBO makes adjustments to cardinality estimates for out of range values appeared in predicates

  • General queries regarding explain plan and query

    Hello Oracle buddies,
    I have few badly formed queries with plenty of nested loops, merge join cartesian , plenty of sorting and in the query so many sub queries and all.. The cost of the queries are high like anything.
    some even has 130Crore of cost .
    When I got the chance to look into those quries I test them in Non Prod systems and which almost have 90-95% similar data as it was refresh by PROD few weeks back.
    I found few queries are having the same explain plan but cost is less like anything. for example 5000 or 6000.
    When I check for the possibilities of wrong statistics I found they just collect with default setting...
    In Non prod I saw only the auto stat job is ran and most of the tables are having the stats which are of last analyzed on the day of refresh.
    Now what could be so differentiating factor that drives a queries' cost lesser than Prod systems, when the data is almost same. Also if prod ssystem is gather by only gather_schema_stat('SCHEMA_NAME') then it should carry the same stat in non prod while refreshing. I know ppl do not gather stat on test only auto job is running ...
    I need to have clear prove before I can have a clear understanding..
    Please help me to know what factors could be differentiating?
    -Regards,
    J_DBA_Sourav

    j_DBA_sourav wrote:
    Hello Jonathan,
    Thanks for the reply. The team refreshed it, by expdp/impdp method where by default statistics are included. In that case?
    Is this problem probable to happen due to statistics only or anything else is also responsible. Even the explain plan is same.
    Please through some light on it.
    Auto job is on as I stated earlier but in test systems most of the tables are showing refreshed date as last_analyzed
    -Regards
    JDS
    Anything that puts the stats out of sync with each other may be sufficient to cause problems. Any queries that depend on sysdate may cause a problem.
    As a simple check:  select table_name, last_analyzed from user_tables on the two systems, with some order by clause (e.g. table_name), and see how many tables were analysed at different times - anything on either system after the exp/imp could be part of your problem.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    Now on Twitter: @jloracle

  • Query of explain plan

    1)explain plan
    set statement_id='anu_a_1'
    for select i.name from a i,b j
    where i.id=j.id1
    order by i.id
    when i am trying to select rows from plan table
    what is the purpose of id,parent_id column
    what is the meaning of these output which is associated with 1st query.
    OPERATION          OPTIONS          
    SORT               ORDER BY     
    when i am trying to run 2nd query
    2)explain plan
    set statement_id='anu_a_1'
    for select * from a
    where id=10
    order by id
    OPERATION          OPTIONS          
    SORT               ORDER BY
    these are not come
    why i am using here same order by clause.

    Study the documentation.
    http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96533/opt_ops.htm#1005137
    SORT ORDER BY
    SORT ORDER BY is required when the statement specifies an ORDER BY that cannot be satisfied by one of the indexes
    Rgds.

  • Any room for improvement for this query? Explain Plan attached.

    Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??
    select sum(CONF
                 when (cd.actl_qty - cd.total_alloc_qty - lsd.Q < 0) then
                  0
                 else
                  cd.actl_qty - cd.total_alloc_qty - lsd.Q
               end)
      from (select sum(reqd_qty) as Q, ITEM_ID as ITEM
              from SHIP_DTL SD
             where exists (select 1
                      from CONF_dtl
                     where CONF_nbr = '1'
                       and ITEM_id = SD.ITEM_id)
             group by ITEM_id) lsd,
           CONF_dtl cd
    where lsd.ITEM = cd.ITEM_id
       and cd.CONF_nbr = '1'Total number of rows in the tables involved
    select count(*) from CONF_DTL;
      COUNT(*)
       1785889
    select count(*) from shp_dtl;
      COUNT(*)
        286675
      Explain Plan
    PLAN_TABLE_OUTPUT
    Plan hash value: 2325658044
    | Id  | Operation                           | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                    |                    |     1 |    39 |     4  (25)| 00:00:01 |
    |   1 |  SORT AGGREGATE                     |                    |     1 |    39 |            |          |
    |   2 |   VIEW                              |                    |     1 |    39 |     4  (25)| 00:00:01 |
    |   3 |    HASH GROUP BY                    |                    |     1 |   117 |     4  (25)| 00:00:01 |
    |   4 |     TABLE ACCESS BY INDEX ROWID     | SHIP_DTL           |     1 |    15 |     1   (0)| 00:00:01
    |   5 |      NESTED LOOPS                   |                    |     1 |   117 |     3   (0)| 00:00:01 |
    |   6 |       MERGE JOIN CARTESIAN          |                    |     1 |   102 |     2   (0)| 00:00:01 |
    |   7 |        TABLE ACCESS BY INDEX ROWID  | CONF_DTL           |     1 |    70 |     1   (0)| 00:00:01 |
    |*  8 |         INDEX RANGE SCAN            | PK_CONF_DTL        |     1 |       |     1   (0)| 00:00:01 |
    |   9 |        BUFFER SORT                  |                    |     1 |    32 |     1   (0)| 00:00:01 |
    |  10 |         SORT UNIQUE                 |                    |     1 |    32 |     1   (0)| 00:00:01 |
    |  11 |          TABLE ACCESS BY INDEX ROWID| CONF_DTL           |     1 |    32 |     1   (0)| 00:00:01 |
    |* 12 |           INDEX RANGE SCAN          | PK_CONF_DTL        |     1 |       |     1   (0)| 00:00:01 |
    |* 13 |       INDEX RANGE SCAN              | SHIP_DTL_IND_6 |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       8 - access("CD"."CONF_NBR"='1')
      12 - access("CONF_NBR"='1')
      13 - access("ITEM_ID"="SD"."ITEM_ID")
           filter("ITEM_ID"="CD"."ITEM_ID")

    Citizen_2 wrote:
    Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??You say that the table stats are up-to-date, but is the following assumption of the optimizer correct:
    select count(*)
    from CONF_dtl
    where CONF_nbr = '1';Does this query return a count of 1? I doubt that, but that's what Oracle estimates in the EXPLAIN PLAN output. Based on that assumption you get a cartesian join between the two CONF_DTL table instances, and the result - which is still expected to be one row at most - is then joined to the SHIP_DTL table using a NESTED LOOP.
    If above assumption is incorrect, the number of rows generated by the cartesian join can be tremendous rendering the NESTED LOOP operation quite inefficient.
    You can verify this by using the DBMS_XPLAN.DISPLAY_CURSOR function together with the GATHER_PLAN_STATISTICS hint, if you're already on 10g or later.
    For more information regarding the DISPLAY_CURSOR function, see e.g. here: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
    It will show you the actual cardinalities compared to the estimated cardinalities.
    If the estimate of the optimizer is incorrect, you should find out why. There still might be some issues with the statistics, since this is most obvious reason for incorrect estimates.
    Are your index statistics up-to-date?
    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/

  • Query with Explain Plan

    Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
    i.e.
    Explain Plan for : Select * from emp a;
    and Explain for : Select * from emp b;
    Will remain same always, or it will differ?
    Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
    Thanks in Advance.
    Regards,
    Sudipta.

    user13513014 wrote:
    Suppose, i am using two queries [ which are almost equal] but using separate table name aliases. Will this result is separate Explain Plans?
    i.e.
    Explain Plan for : Select * from emp a;
    and Explain for : Select * from emp b;
    Will remain same always, or it will differ? By simply switching alias, the optimizer is unlikely to develop a new plan.
    Also, i was looking for low level conversion of Parsed SQL statements to Machine Level Language. I mean how this step is performed. Where does the compiler/interpreter resides and how it works.
    Thanks in Advance.
    Regards,
    Sudipta.There is no way you can actally see the parsing of SQL. It is done internally by oracle in a process caled Hard Parse or Soft Parse. A Hard Parse is where the optimizer must go through all the steps of parsing from the beggining, where as a soft parse, oracle uses the cached results from a hard parsed query that is in the shared pool.
    How the optimizer works is a subject of ample documentation and several books. As a general over view, here are the general steps at parsing an SQL:
    1. Optimizer evaluates your statement, checks it for grammar errors, grants to objects, etc.
    2. Statement Transformation: Optimizer evaluates your statement for possible optimization regarding rewrite, in cases you have view or correlated subqueries.
    3. Choice of optimizer goals.
    4. Choice of acccess paths.
    5. Choice of Join Orders.
    Suggest you try a google search, it will give you a lot of material, or check the Oracle Database Performance Tuning Guide 11.2, which is free by oracle.

  • 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 for query with variables

    Trying to Explain plan for some sql in sql*plus. The query has a variable in it. How do I do this ?
    I did look into explain plan and dbms_xplan but could not find anything with variables

    use sqlplus bind variables:
    SQL> --define variable
    SQL> var x varchar2
    SQL> -- notice the colon prefixing the variable
    SQL> explain plan for select * from customer where cid = :x;
    Explained.
    SQL> select * from table( dbms_xplan.display );
    PLAN_TABLE_OUTPUT
    Plan hash value: 1709312366
    | Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |          |     1 |    67 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| CUSTOMER |     1 |    67 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | CID      |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("CID"=:X)
    14 rows selected.the variable does not need to be set to explain the query, since explain does not actually execute.
    Edited by: shoblock on Nov 6, 2008 4:51 PM

  • Explain plan for Query performance

    Hi Gurus,
    I need to improve the performance of a procedure. The procedure has the below QUery. I dont have Idea on how to imrpove the perf by seeing the explain plan. Can anyone please help me to explain where I need to change the code.
    The below are the code and Explain plan for the same.
    -----------Code----------------------------
    SELECT IV_STORECODE AS STORECODE,
                                   TO_CHAR(RD.ITEMCODE) AS ITEMCODE,
                                   C.ITEMCATEGORYNAME,
                                   ISUB.ITEMSUBCATEGORY1NAME
                              FROM RECEIPTS R
                             INNER JOIN RECEIPTDETAILS RD
                                ON R.RECEIPTID = RD.RECEIPTID
                             INNER JOIN ITEMCOMPANY IC
                                ON IC.ITEMCODE = RD.ITEMCODE
                             INNER JOIN ITEMCATEGORY C
                                ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
                             LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
                                ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
                               AND ISUB.ITEMSUBCATEGORY1ID IN
                                   (SELECT ITEMSUBCATEGORY1ID
                                      FROM ITEMSUBCATEGORY1
                                     WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
                             INNER JOIN STORE SE
                                ON SE.STORECODE = R.STORECODE
                             WHERE R.STORECODE = IV_STORECODE
                               AND SE.HOSPITALID = IV_HOSPITALID
                               AND TRUNC(R.CREATEDDATE) BETWEEN V_FROMDATE AND
                                   V_TODATE
                               AND R.STATUSID NOT IN (99, 5)
                                  AND
                                   (IV_DRUGTYPE IS NULL OR
                                   IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
                            UNION
                            SELECT IV_STORECODE AS STORECODE,
                                   TO_CHAR(STD.ITEMCODE) AS ITEMCODE,
                                   C.ITEMCATEGORYNAME,
                                   ISUB.ITEMSUBCATEGORY1NAME
                              FROM STOCKTRANSACTION ST
                             INNER JOIN STOCKTRANSACTIONDETAILS STD
                                ON ST.STOCKTRANSACTIONID = STD.STOCKTRANSACTIONID
                             INNER JOIN ITEMCOMPANY IC
                                ON IC.ITEMCODE = STD.ITEMCODE
                             INNER JOIN ITEMCATEGORY C
                                ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
                              LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
                                ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
                               AND ISUB.ITEMSUBCATEGORY1ID IN
                                   (SELECT ITEMSUBCATEGORY1ID
                                      FROM ITEMSUBCATEGORY1
                                     WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
                             INNER JOIN STORE SE
                                ON SE.STORECODE = ST.STORECODE
                             WHERE ST.STORECODE = IV_STORECODE
                               AND SE.HOSPITALID = IV_HOSPITALID
                               AND TRUNC(ST.CREATEDDATE) BETWEEN V_FROMDATE AND
                                   V_TODATE
                               AND ST.STATUS <> 99
                               AND STD.ITEMCODE NOT LIKE '%#%'
                               AND                   
                                   (IV_DRUGTYPE IS NULL OR
                                   IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
                            UNION
                            SELECT D.STORECODE,
                                   TO_CHAR(D.ITEMCODE) AS ITEMCODE,
                                   C.ITEMCATEGORYNAME,
                                   ISUB.ITEMSUBCATEGORY1NAME
                              FROM DAILYINVENTORY D
                             INNER JOIN ITEMCOMPANY IC
                                ON IC.ITEMCODE = D.ITEMCODE
                             INNER JOIN ITEMCATEGORY C
                                ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
                              LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
                                ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
                               AND ISUB.ITEMSUBCATEGORY1ID IN
                                   (SELECT ITEMSUBCATEGORY1ID
                                      FROM ITEMSUBCATEGORY1
                                     WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
                             INNER JOIN STORE SE
                                ON SE.STORECODE = D.STORECODE
                             WHERE D.STORECODE = IV_STORECODE
                               AND SE.HOSPITALID = IV_HOSPITALID
                               AND TRUNC(D.UPDATEDDATE) <= V_TODATE
                               AND D.QTY > 0
                               AND D.ITEMCODE NOT LIKE '%#%'
                               AND C.ITEMCATEGORYID = IV_ITEMCATEGORY
                                  AND (IV_DRUGTYPE IS NULL OR
                                   IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
                               AND (IV_SUBITEMCATEGORY IS NULL OR
                                   ISUB.ITEMSUBCATEGORY1ID = IV_SUBITEMCATEGORY) Will post the explain plan ..
    Thanks in advance..

    Ensure you also include all the other information people will need to help you, e.g. database version, table structures/relationships and cardinalities, row counts etc.
    See the two threads linked to in the FAQ: {message:id=9360003}

  • Strange explain plan when query SYS tables

    Oracle Version 9.2.0.7
    We have an application that runs the following query on Oracle 9.2.0.7
    SELECT T1.TABLE_NAME,T1.COLUMN_NAME, T1.SRID, T2.SDO_UB, T2.SDO_LB, T1.OWNER FROM ALL_SDO_GEOM_METADATA T1, TABLE(T1.DIMINFO) T2 WHERE T1.OWNER=UPPER(:"SYS_B_0") AND T1.TABLE_NAME=UPPER(:"SYS_B_1")
    Without the self join the query is fine, but with the self join on our customers database the explain plan is doing full table scans and Hash Joins on SYS tables and takes 2 minutes.
    Rows Row Source Operation
    2 FILTER
    2 NESTED LOOPS
    1 TABLE ACCESS FULL SDO_GEOM_METADATA_TABLE
    2 COLLECTION ITERATOR PICKLER FETCH
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    37 TABLE ACCESS FULL TS$
    0 HASH JOIN OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS OUTER
    0 HASH JOIN
    54 TABLE ACCESS FULL USER$
    0 HASH JOIN
    29447 TABLE ACCESS FULL OBJ$
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 HASH JOIN OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS FULL USER$
    0 TABLE ACCESS FULL OBJ$
    0 TABLE ACCESS FULL USER$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    On our development database it takes 0.07 sec with no full table scans and no hash joins.
    Rows Row Source Operation
    2 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
    1 INDEX RANGE SCAN SDO_GEOM_IDX (object id 36753)
    1 UNION-ALL
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    0 NESTED LOOPS
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN I_OBJ# (object id 3)
    0 TABLE ACCESS CLUSTER TS$
    0 INDEX UNIQUE SCAN I_TS# (object id 7)
    0 TABLE ACCESS CLUSTER COL$
    0 TABLE ACCESS CLUSTER COLTYPE$
    0 TABLE ACCESS CLUSTER SEG$
    0 INDEX UNIQUE SCAN I_FILE#_BLOCK# (object id 9)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 INDEX UNIQUE SCAN I_OBJ1 (object id 36)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX RANGE SCAN I_OBJ3 (object id 38)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN I_USER# (object id 11)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS BY INDEX ROWID USER$
    1 INDEX UNIQUE SCAN I_USER1 (object id 44)
    1 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX RANGE SCAN I_OBJ2 (object id 37)
    0 INDEX UNIQUE SCAN I_TYPED_VIEW1 (object id 105)
    1 INDEX UNIQUE SCAN I_VIEW1 (object id 104)
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN I_OBJAUTH2 (object id 109)
    0 FIXED TABLE FULL X$KZSPR
    2 COLLECTION ITERATOR PICKLER FETCH
    ALL_SDO_GEOM_METADATA is a view in the MDSYS schema (generated by Oracle ).
    SELECT SDO_OWNER OWNER,
    SDO_TABLE_NAME TABLE_NAME,
    SDO_COLUMN_NAME COLUMN_NAME,
    SDO_DIMINFO DIMINFO,
    SDO_SRID SRID
    FROM SDO_GEOM_METADATA_TABLE
    WHERE
    (exists
    (select table_name from all_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select table_name from all_object_tables
    where table_name=sdo_table_name
    and owner = sdo_owner
    union all
    select view_name table_name from all_views
    where view_name=sdo_table_name
    and owner = sdo_owner))
    Statistics have been gathered for the MDSYS user.
    If this had not been SYS schema I would have immediately concluded that fresh statistics are required. The SYS objects concerend are valid with all indexes
    From my understanding you are not meant to gather stats for the SYS schema in Oracle 9 as Data Dictionary queries still uses RBO?
    Any ideas as to why Oracle is doing full table scans when querying SYS tables? The optimizer_mode is set to FIRST_ROWS.
    Any ideas greatly recevied.
    Thanks

    Maybe I'm missing something but this:
    INDEX FULL SCAN     SISESTAT     I0_ESTRUTURA_COMERCIALindicates that one of those indexes is being used.
    This:
    T_ESTRUTURA_COMERCIALIs nowhere to be found in your Explain Plan. It appears that either you have posted the wrong plan
    or Oracle is doing a query rewrite to a materialized view.

  • Understanding meaning of a query's explain plan

    Hi,
    I have a simple query but its query plan is looking difficult for me to understand. Can someone help me explain step by step what happens inthe query. I mean "first step table emp is full scan , than next step is another table's scan..." etc - in that way. I can't make out and need help to understand.
    SQL> explain plan for
      2  SELECT ename,dname ,grade
      3  from n1.salgrade salgrade ,n1.emp emp,n1.dept dept
      4  where emp.deptno=dept.deptno and
      5  emp.sal between salgrade.losal and salgrade.hisal;
    SQL> select plan_table_output from table(dbms_xplan.display());
    Plan hash value: 4131418678
    | Id  | Operation             | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |          |     1 |    36 |    12  (25)| 00:00:01 |
    |*  1 |  HASH JOIN            |          |     1 |    36 |    12  (25)| 00:00:01 |
    |   2 |   MERGE JOIN          |          |     1 |    23 |     8  (25)| 00:00:01 |
    |   3 |    SORT JOIN          |          |     5 |    50 |     4  (25)| 00:00:01 |
    |   4 |     TABLE ACCESS FULL | SALGRADE |     5 |    50 |     3   (0)| 00:00:01 |
    |*  5 |    FILTER             |          |       |       |            |          |
    |*  6 |     SORT JOIN         |          |    14 |   182 |     4  (25)| 00:00:01 |
    |   7 |      TABLE ACCESS FULL| EMP      |    14 |   182 |     3   (0)| 00:00:01 |
    |   8 |   TABLE ACCESS FULL   | DEPT     |     4 |    52 |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")
       5 - filter("EMP"."SAL"<="SALGRADE"."HISAL")
       6 - access("EMP"."SAL">="SALGRADE"."LOSAL")
           filter("EMP"."SAL">="SALGRADE"."LOSAL")for example my question is why there is SORT JOIN on step no 6? does it mean that rows obtained from step 7 are sorted? than what is done during the step of FILTER?why there are so many joins. Basically I am not good in this area so need help.
    Thanks
    Edited by: orausern on Sep 23, 2010 11:58 AM

    The operations are performed in the following order: 4, 3, 7, 6, 5, 2, 8, 1, 0. The Merge Join operation in Node 2 consumes the SALGRADE and EMP records produced by Node 3 and Node 5 respectively. Node 3 and Node 5 are therefore visited repeatedly during the Merge Join operation. Whenever Node 3 produces a SALGRADE record, Node 5 tries to produce matching EMP records. Node 6 produces EMP records that satisfy the condition EMP.SAL >= SALGRADE.LOSAL. Node 5 then checks if the EMP records produced by Node 6 satisfy the additional condition EMP.SAL <= SALGRADE.HISAL before releasing them. All the results of the Merge Join operation are stored in a hash table in memory. Once the construction of the hash table is fully complete, the DEPT table is scanned and each DEPT record is checked using the hash table.
    Iggy

  • Explain plan for query

    HI all
    Please help to evaluate the explian plan for query suppose the following is the plan
    | Id  | Operation                        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                 |                  |     7 |  1260 |   303   (1)| 00:00:04 |
    |   1 |  SORT ORDER BY                   |                  |     7 |  1260 |   303   (1)| 00:00:04 |
    |*  2 |   FILTER                         |                  |       |       |            |          |
    |   3 |    NESTED LOOPS                  |                  |       |       |            |          |
    |   4 |     NESTED LOOPS                 |                  |     7 |  1260 |   302   (1)| 00:00:04 |
    |   5 |      NESTED LOOPS                |                  |     7 |   791 |   281   (1)| 00:00:04 |
    PLAN_TABLE_OUTPUT                                                                                      
    |*  6 |       TABLE ACCESS BY INDEX ROWID| TASKDETAIL       |     7 |   574 |   267   (1)| 00:00:04 |
    |*  7 |        INDEX SKIP SCAN           | IDX_TD_TTS       |  2726 |       |    29   (0)| 00:00:01 |
    |*  8 |       TABLE ACCESS BY INDEX ROWID| ORDERS           |     1 |    31 |     2   (0)| 00:00:01 |
    |*  9 |        INDEX UNIQUE SCAN         | PK_SYS_C004711   |     1 |       |     1   (0)| 00:00:01 |
    |* 10 |      INDEX RANGE SCAN            | TEPS_PICK_INDEX1 |     1 |       |     2   (0)| 00:00:01 |
    |* 11 |     TABLE ACCESS BY INDEX ROWID  | TASK_PICK_EPS    |     1 |    67 |     3   (0)| 00:00:01 |
    -----------------------------------------------------------------------------------------------------1. what are the columns rows ,bytes,cost ,time indicate us

    The current 11.2 version of the documentation (URL below) would be better than the 9.2 version
    http://docs.oracle.com/cd/E11882_01/server.112/e16638/ex_plan.htm#i19260
    "Rows" is the expected number of rows that will be returned by that step of the plan
    "Bytes" is the expected size of the result set returned by that step of the plan
    "Time" is the expected execution time --- this can be grossly off because Oracle uses some assumptions about singe block read time, multiblock read time and CPU speed.
    Hemant K Chitale
    Edited by: Hemant K Chitale on Sep 25, 2012 3:04 PM

  • Is there any way to tune this query? EXPLAIN PLAN included

    DB version:10gR2
    The below query was taking more than 3 seconds. The statistics are up to date for these tables. Is there any other way i could tune this query?
    SELECT COUNT(1)
    FROM
    INVN_SCOPE_DTL, ship_dtl WHERE ship_dtl.WHSE = INVN_SCOPE_DTL.WHSE (+)
    AND 'QC' = INVN_SCOPE_DTL.FROM_WORK_GRP (+)
    AND  'MQN' = INVN_SCOPE_DTL.FROM_WORK_AREA (+)
    AND  ship_dtl.START_CURR_WORK_GRP = INVN_SCOPE_DTL.TO_WORK_GRP (+)
    AND  ship_dtl.START_CURR_WORK_AREA = INVN_SCOPE_DTL.TO_WORK_AREA (+)
    AND  ship_dtl.WHSE = '930' AND  ship_dtl.OWNER_USER_ID = 'CTZDM'
    OR ship_dtl.OWNER_USER_ID = '*'
    AND ship_dtl.STAT_CODE >= '10'
    AND ship_dtl.STAT_CODE <= '20'
    ORDER BY ship_dtl.OWNER_USER_ID DESC,
    ship_dtl.CURR_TASK_PRTY ASC, INVN_SCOPE_DTL.DISTANCE ASC, ship_dtl.RLS_DATE_TIME ASC, ship_dtl.TASK_ID ASC;
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id  | Operation                      |  Name               | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT               |                     |     1 |    86 |    86   (2)|
    |   1 |  SORT AGGREGATE                |                     |     1 |    86 |            |
    |   2 |   NESTED LOOPS OUTER           |                     |   898 | 77228 |    86   (2)|
    |   3 |    INLIST ITERATOR             |                     |       |       |            |
    |*  4 |     TABLE ACCESS BY INDEX ROWID| ship_dtl            |   898 | 31430 |    85   (2)|
    |*  5 |      INDEX RANGE SCAN          | ship_dtl_IND_4      |  2876 |       |     1   (0)|
    |   6 |    TABLE ACCESS BY INDEX ROWID | INVN_SCOPE_DTL     |     1 |    51 |     2  (50)|
    PLAN_TABLE_OUTPUT
    |*  7 |     INDEX UNIQUE SCAN          | PK_INVN_SCOPE_DTL  |     1 |       |            |
    Predicate Information (identified by operation id):
       4 - filter("ship_dtl"."WHSE"='930' AND "ship_dtl"."STAT_CODE">=10 AND
                  "ship_dtl"."STAT_CODE"<=20)
       5 - access("ship_dtl"."OWNER_USER_ID"='*' OR "ship_dtl"."OWNER_USER_ID"='CTZDM')
       7 - access("INVN_SCOPE_DTL"."WHSE"(+)='930' AND
                  "INVN_SCOPE_DTL"."FROM_WORK_GRP"(+)='QC' AND "INVN_SCOPE_DTL"."FROM_WORK_AREA"(+)='MQN'
    PLAN_TABLE_OUTPUT
                  AND "ship_dtl"."START_CURR_WORK_GRP"="INVN_SCOPE_DTL"."TO_WORK_GRP"(+) AND
                  "ship_dtl"."START_CURR_WORK_AREA"="INVN_SCOPE_DTL"."TO_WORK_AREA"(+))
           filter("ship_dtl"."WHSE"="INVN_SCOPE_DTL"."WHSE"(+))
    25 rows selected.

    William Robertson wrote:
    I notice an OR predicate in the middle of some AND predicates without explicit bracketing. Are you sure it does what you think it does?I underline this point.
    A conjuction (AND expression) has a higher priority and will be executed (logically) before the disjunction (OR expression)! So your select looks like this
    SELECT COUNT(1)
    FROM INVN_SCOPE_DTL, ship_dtl
    WHERE
          ( ship_dtl.WHSE = INVN_SCOPE_DTL.WHSE (+)
          AND 'QC' = INVN_SCOPE_DTL.FROM_WORK_GRP (+)
          AND  'MQN' = INVN_SCOPE_DTL.FROM_WORK_AREA (+)
          AND  ship_dtl.START_CURR_WORK_GRP = INVN_SCOPE_DTL.TO_WORK_GRP (+)
          AND  ship_dtl.START_CURR_WORK_AREA = INVN_SCOPE_DTL.TO_WORK_AREA (+)
          AND  ship_dtl.WHSE = '930'
          AND  ship_dtl.OWNER_USER_ID = 'CTZDM'
    OR   ( ship_dtl.OWNER_USER_ID = '*'
          AND ship_dtl.STAT_CODE >= '10'
          AND ship_dtl.STAT_CODE <= '20'
    ;This might be want you want, but I doubt it very much. Please add parenthesis', to get it working the way it should be.
    Edited by: Sven W. on Oct 16, 2008 3:25 PM

  • Regarding explain plan

    hi all,
    i am using database 10g.
    i have explain as below
    SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2715695103
    | Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time
       |
    |   0 | SELECT STATEMENT              |                        |     8 |   568 |     6  (17)| 00:00:
    01 |
    |   1 |  HASH UNIQUE                  |                        |     8 |   568 |     6  (17)| 00:00:
    01 |
    |   2 |   NESTED LOOPS                |                        |     8 |   568 |     5   (0)| 00:00:
    01 |
    |*  3 |    TABLE ACCESS FULL          | COMMON_PURCHASE_HEADER |     8 |   232 |     3   (0)| 00:00:
    PLAN_TABLE_OUTPUT
    01 |
    |   4 |    TABLE ACCESS BY INDEX ROWID| CUSTOMER_MASTER        |     1 |    42 |     1   (0)| 00:00:
    01 |
    |*  5 |     INDEX UNIQUE SCAN         | CUM_PK                 |     1 |       |     0   (0)| 00:00:
    01 |
    ----how we can analyse the query based on this plan.
    Thanks..

    What do you think an execution plan is? I think you think that this tells you all by itself how "good" the query is. No that's wrong. You can compare it with the advise a GPS system gives you to go from A to B. Some GPS system give better advices than others, some even know the current traffic situation. But, without any knowledge about the location you are in, you have to trust that plan.
    But, if you live in that area, you might know that another path might me faster than the suggested one,etc.
    All ORACLE tells you with this execution plan, is that it will read table COMMON_PURCHASE_HEADER completely and will join CUSTOMER_MASTER in a nested loop over the PK index.
    WE do now know a lot about your DB, if there are other indexes (e.g. on C_STATUS) and what the cardinality on it is. If there would be an index, and the value A would just occur once, an INDEX lookup might be faster if you would have MUCH moire data!
    On 8 rows....as the optimizer believes all data is on the same block and is read by 1 IO and that's the fastest access.
    So, basically you need to learn what ORACLE tries to do.
    Then you ask yourself, as you know the DB, if that's a clever idea.
    If it's not, ask yourself why ORACLE does not agree with you. It might still be right. So test your access methods with hints, and you will see and learn.
    As I said it's like the advice a GPS system gives you. Only a local can really tell you how clever that suggestion is. (And the local can be wrong) ;-)

  • Need help th tuning query or re write the query--

    Hi,
    Need help to tune the below query or rewrite th query for reducing the execution time Please find the query and explain plan.
    QUERY
    explain plan FOR SELECT consumer_key,product_key,days_in_product,20100201 period_key FROM
    (SELECT consumer_key,
      product_key,
      days_in_product,
      row_number() over ( Partition BY consumer_key order by Days_in_product DESC) row_num
    FROM
      (SELECT consumer_key,
        product_key,
        SUM(no_ofdays) days_in_product
      FROM
        (SELECT pcv.consumer_key,
          pcv.product_key,
          pcv.product_consumer_valid_from,
          pcv.product_consumer_valid_to,
          DECODE (SIGN(20100201000000-product_consumer_valid_from),1,20100201000000,product_consumer_valid_from) period_start,
          DECODE (SIGN(20100228235959-product_consumer_valid_to),1,product_consumer_valid_to,20100228235959) period_end,
          CASE
            WHEN to_number(TO_CHAR(cd.activation_date,'YYYYMMDDHH24MISS')) BETWEEN 20100201000000 AND 20100228235959
            AND activation_date > to_Date(product_consumer_valid_to,'YYYYMMDDHH24MISS')
            THEN 0
            WHEN to_number(TO_CHAR(cd.activation_date,'YYYYMMDDHH24MISS')) BETWEEN 20100201000000 AND 20100228235959
            AND activation_date BETWEEN to_Date(product_consumer_valid_from,'YYYYMMDDHH24MISS') AND to_Date(product_consumer_valid_to,'YYYYMMDDHH24MISS')
            THEN
              --to_char(activation_date,'MON-YYYY')='PERIOD_ACTIVE'  and activation_date >= to_Date(product_consumer_valid_from,'YYYYMMDDHH24MISS') then
              (to_date(DECODE (SIGN(20100228235959-product_consumer_valid_to),1,product_consumer_valid_to,20100228235959),'YYYYMMDDHH24MISS') - to_date(TO_CHAR(activation_date,'YYYYMMDDHH24MISS'),'YYYYMMDDHH24MISS') )
            WHEN to_number(TO_CHAR(cd.activation_date,'YYYYMMDDHH24MISS')) < 20100201000000
            THEN (to_date(DECODE (SIGN(20100228235959-product_consumer_valid_to),1,product_consumer_valid_to,20100228235959),'YYYYMMDDHH24MISS') - to_Date(DECODE (SIGN(20100201000000-product_consumer_valid_from),1,20100201000000,product_consumer_valid_from),'YYYYMMDDHH24MISS') )
            WHEN to_number(TO_CHAR(cd.activation_date,'YYYYMMDDHH24MISS')) > 20100228235959
            THEN 0
            ELSE
              --unusual situation
              (to_date(DECODE (SIGN(20100228235959-product_consumer_valid_to),1,product_consumer_valid_to,20100228235959),'YYYYMMDDHH24MISS') - to_Date(DECODE (SIGN(20100201000000-product_consumer_valid_from),1,20100201000000,product_consumer_valid_from),'YYYYMMDDHH24MISS') )
          END No_ofDays
        FROM cimtran.product_consumer_validity pcv,
          consumer_dimension cd
        WHERE pcv.consumer_key           =cd.consumer_key
        AND product_consumer_valid_to   >= 20100201000000
        AND product_consumer_valid_from <= 20100228235959
          --and product_consumer_valid_from > '20090801000000'
        ORDER BY consumer_key,
          product_key,
          product_consumer_valid_from
        ) a
      GROUP BY consumer_key,
        product_key
      ORDER BY consumer_key,
        product_key
    ) WHERE row_num=1 ;EXPLAIN PLAN
    "PLAN_TABLE_OUTPUT"
    "Plan hash value: 3823907703"
    "| Id  | Operation                | Name                      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |"
    "|   0 | SELECT STATEMENT         |                           |  4665K|   231M|       |   133K  (1)| 00:31:08 |"
    "|*  1 |  VIEW                    |                           |  4665K|   231M|       |   133K  (1)| 00:31:08 |"
    "|*  2 |   WINDOW SORT PUSHED RANK|                           |  4665K|   173M|   232M|   133K  (1)| 00:31:08 |"
    "|   3 |    VIEW                  |                           |  4665K|   173M|       |   104K  (1)| 00:24:18 |"
    "|   4 |     SORT GROUP BY        |                           |  4665K|   182M|   729M|   104K  (1)| 00:24:18 |"
    "|*  5 |      HASH JOIN           |                           |    13M|   533M|    65M| 44241   (1)| 00:10:20 |"
    "|   6 |       TABLE ACCESS FULL  | CONSUMER_DIMENSION        |  2657K|    35M|       |  4337   (1)| 00:01:01 |"
    "|*  7 |       TABLE ACCESS FULL  | PRODUCT_CONSUMER_VALIDITY |    13M|   351M|       | 15340   (2)| 00:03:35 |"
    "Predicate Information (identified by operation id):"
    "   1 - filter(""ROW_NUM""=1)"
    "   2 - filter(ROW_NUMBER() OVER ( PARTITION BY ""CONSUMER_KEY"" ORDER BY "
    "              INTERNAL_FUNCTION(""DAYS_IN_PRODUCT"") DESC )<=1)"
    "   5 - access(""PCV"".""CONSUMER_KEY""=""CD"".""CONSUMER_KEY"")"
    "   7 - filter(""PRODUCT_CONSUMER_VALID_FROM""<=20100228235959 AND "
    "              ""PRODUCT_CONSUMER_VALID_TO"">=20100201000000)"

    I doubt that this query can be tuned without using indexes. There is a lot of unnecessary work specified in your query, like unnecessary intermediate sorting and selecting unused columns. The cost based optimizer recognized it and skips some of that unnecessary work, it seems. For clarity's sake, I would rewrite your query like below. Note that the query is untested:
    select consumer_key
         , max(product_key) keep (dense_rank last order by days_in_product) product_key
         , max(days_in_product) days_in_product
         , 20100201 period_key
      from ( select pcv.consumer_key
                  , pcv.product_key
                  , sum
                    ( case
                      when to_number(to_char(cd.activation_date,'yyyymmddhh24miss')) between 20100201000000 and 20100228235959
                      then
                        case
                        when cd.activation_date > to_date(pcv.product_consumer_valid_to,'yyyymmddhh24miss')
                        then
                          0
                        when cd.activation_date between to_date(pcv.product_consumer_valid_from,'yyyymmddhh24miss') and to_date(product_consumer_valid_to,'yyyymmddhh24miss')
                        then
                          to_date(to_char(pcv.product_consumer_valid_to),'yyyymmddhh24miss'))
                          - to_date(to_char(activation_date,'yyyymmddhh24miss'),'yyyymmddhh24miss')
                        end
                      when to_number(to_char(cd.activation_date,'yyyymmddhh24miss')) < 20100201000000
                      then
                        to_date(to_char(pcv.product_consumer_valid_to),'yyyymmddhh24miss'))
                        - to_date(to_char(pcv.product_consumer_valid_from),'yyyymmddhh24miss'))
                      when to_number(to_char(cd.activation_date,'yyyymmddhh24miss')) > 20100228235959
                      then
                        0
                      end
                    ) days_in_product
               from cimtran.product_consumer_validity pcv
                  , consumer_dimension cd
              where pcv.consumer_key             = cd.consumer_key
                and product_consumer_valid_to   >= 20100201000000
                and product_consumer_valid_from <= 20100228235959
              group by consumer_key
                  , product_key
    group by consumer_keyRegards,
    Rob.

Maybe you are looking for

  • FaceTime no longer wotking on my iPhone 4 (GSM) iOS 6.1.4

    Hello everyone, My last successful FaceTime call was made on August 31, 2013. When I tried to answer / initiate a FaceTime call to a family member over the weekend, I discovered that FT would attempt to connect, but fail to complete. I have since dis

  • Every Time I Open/Create A Document It Opens A New Window In PS CC

    -=PLEASE HELP=- I have Photoshop CC, And everytime I open/create a document it makes a new window. What I really want is it not to make a new window, and just do it's normal thing. This Is a problem for a numerous reasons. #1 I Cant see layers of doc

  • Patch for TVKOL

    Hi All, Can any one give me the path for TVKOL. I need to add new storage condition to shipping point, plant and storage location. Regards, Ravi

  • Problem downloading previously downloaded app

    i previously downloaded padora raido and for some reason delieted it from one of my ipads.  Now when i go to update or redownload it from the app store it is grayed out and i can't click on it.  Please advise thanks

  • Is anyone else having problems with Font Book?

    Recently tried to add some Hallowe'en fonts. Font Book seems to start, i.e., the first page opens, but it refuses to add the font, and sits there spinning the beachball. I have to force quit, get a demand to report to Apple - which I have now done 3-