Wrong index usage in execution plan

I have one large document in container created with DBXML_INDEX_NODES flag.
There is an index by "high" attribute node
self.container.addIndex ( "", "high", "edge-attribute-equality-double", self.uc )
About 50% of elements in document have structure:
<record><data high="XX.XX" /></record>
Which are inside "session" element which is itself inside "log" element. Only one "log" and one "session" element exist in document
Index by “high” attribute node is very selective. Below is execution plan (changing index to "node" doesn't change things). Index is used on "presence" of "high" attribute and not "value" of it. I think using it for value would improve the speed of the query. Here is the query produced the execution plan below "collection ( 'test.dbxml' )/log/session/record[data/@high=79.37]"
<XQuery>
<Navigation>
<QueryPlanFunction result="collection" container="seasonal.dbxml">
<OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
</QueryPlanFunction>
<Step axis="child" name="log" nodeType="element"/>
<Step axis="child" name="session" nodeType="element"/>
<Step axis="child" name="record" nodeType="element"/>
<DbXmlFilter>
<Navigation>
<Step axis="child" name="data" nodeType="element">
<OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
</Step>
<Step axis="attribute" name="high" nodeType="attribute"/>
<DbXmlCompare name="equal">
<OQPlan>P(edge-attribute-equality-double,prefix,@high)</OQPlan>
<Sequence>
<AnyAtomicTypeConstructor value="79.37" typeuri="http://www.w3.org/2001/XMLSchema" typename="decimal"/>
</Sequence>
</DbXmlCompare>
</Navigation>
</DbXmlFilter>
</Navigation>
</XQuery>
Also, why is the “typename” attribute of “AnyAtomicTypeConstructor” element is “decimal”?
Removing flag DBXML_INDEX_NODES on the container increases speed significantly and produces this execution plan, speed is not acceptable though.
<XQuery>
<Navigation>
<QueryPlanFunction result="collection" container="seasonal.dbxml">
<OQPlan>P(edge-attribute-equality-double,prefix,data.@high)</OQPlan>
</QueryPlanFunction>
<Step axis="child" name="log" nodeType="element"/>
<Step axis="child" name="session" nodeType="element"/>
<Step axis="child" name="record" nodeType="element"/>
<DbXmlFilter>
<Navigation>
<Step axis="child" name="data" nodeType="element"/>
<Step axis="attribute" name="high" nodeType="attribute"/>
<DbXmlCompare name="equal">
<Sequence>
<AnyAtomicTypeConstructor value="79.37" typeuri="http://www.w3.org/2001/XMLSchema" typename="decimal"/>
</Sequence>
</DbXmlCompare>
</Navigation>
</DbXmlFilter>
</Navigation>
</XQuery>
Using index lookup allows achieving speed I need. I'd like to know how to properly write the query and what index to use in my case, though.

Your query is not using the index because the numeric literal you are using is an xs:decimal, not an xs:double. Wrapping your literal in a cast should make the query use your index:
collection ( 'test.dbxml' )/log/session/record[data/@high=xs:double(79.37)]
Having said that, this is only the case for DB XML 2.2.13 and before. It turns out that DB XML has been choosing the wrong type to perform comparisons under - and this has been remedied in the forthcoming version. In your case, the new behaviour will mean that the comparison will always be performed as an xs:double.
John

Similar Messages

  • Wrong Execution Plan getting picked on some occassions

     
    Hi,
    The following query sometimes runs efficiently; gives quick results, CPU and IO utilization is also up to the mark. But sometimes the query takes very long time to execute.
    At that time I do not observe any blocks as well. Also the CPU and IO is too huge for running this query. It seems the engine picks up wrong execution plan some times.
    This query is fired through some product. So there is no scope to change the query. Any suggestions for the engine to pick up right execution plan?
    select i . bpd_instance_id as instanceId , i . instance_name as instanceName , bpd . name as bpdName , istatus . name as instanceStatus , t . subject as taskSubject , tpriority . name as taskPriority , t . due_date as taskDueDate , t . attached_form_ref as taskAttachedInfoPathFormRef , t . attached_ext_activity_ref as taskAttachedExtActivityRef , t . task_id as taskId , tstatus . name as taskStatus , tuser . user_name as assignedToUser , tpriority . ranking as taskPriorityRanking from msadmin.lsw_task t with ( nolock ) inner join msadmin.lsw_bpd_instance i with ( nolock ) on t . bpd_instance_id = i . bpd_instance_id left join msadmin.lsw_task_status_codes tstatus on t . status = tstatus . status_value left join msadmin.lsw_bpd_status_codes istatus on i . execution_status = istatus . status_id left join msadmin.lsw_priority tpriority on t . priority_id = tpriority . priority_id left join msadmin.lsw_bpd bpd on i . cached_bpd_version_id = bpd . version_id left join msadmin.lsw_usr_xref tuser on t . user_id = tuser . user_id where ( t . status in ( '11','12' ) and ( t . user_id = 5909 or t . task_id in (
    select t . task_id
    from msadmin.lsw_task t with ( NOLOCK )
    inner join msadmin.lsw_usr_grp_mem_xref m with ( NOLOCK )
    on t . group_id = m . group_id
    where m . user_id = 5909
    and t . user_id = -1
    ) or t . task_id in (
    select t . task_id
    from msadmin.lsw_task t with ( NOLOCK )
    inner join msadmin.lsw_grp_grp_mem_exploded_xref x with ( NOLOCK )
    on t . group_id = x . container_group_id
    inner join msadmin.lsw_usr_grp_mem_xref m with ( NOLOCK )
    on m . group_id = x . group_id
    where m . user_id = 5909
    and t . user_id = -1
    ) ) ) order by taskDueDate , taskPriorityRanking , instanceId , taskId

    Is it a good practive to update a stat nightly on all the tables with FULL SCAN? will it help to boost the performance?
    Maybe. But it may also be overkill, particularly if you do not have the hours. A somewhat better option may be to run with FULLSCAN, INDEX to only update the statistics for indexes. But note that if you rebuild an index, that updates the statistics for that
    index with FULLSCAN anyway.
    But overall, there are rarely any magic button to performance tuning. In the end, you will need to do the hard work to find the painful queries that need better indexes or needs to be rewritten.
    Erland Sommarskog, SQL Server MVP, [email protected]

  • How to corret an execution plan that shows wrong number of rows?

    Using Oracle 10gR2 RAC (10.2.0.3) on SUSE Linux 9 (x86_64).
    I have a partition table that has 5 million rows (5,597,831). However an execution plan against the table show that the table has 10 million rows.
    Execution plan:
    SELECT STATEMENT ALL_ROWS Cost : 275,751 Bytes : 443 Cardinality : 1
    3 HASH GROUP BY Cost : 275,751 Bytes : 443 Cardinality : 1
         2 PARTITION RANGE ALL Cost : 275,018 Bytes : 4,430,000,000 Cardinality : *10,000,000* Partition # : 2 Partitions accessed #1 - #6
              1 TABLE ACCESS FULL TRACESALES.TRACE_BUSINESS_AREA Cost : 275,018 Bytes : 4,430,000,000 Cardinality : 10,000,000 Partition # : 2 Partitions accessed #1 - #6
    Plan hash value: 322783426
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 443 | 275K (2)| 00:55:10 | | |
    | 1 | HASH GROUP BY | | 1 | 443 | 275K (2)| 00:55:10 | | |
    | 2 | PARTITION RANGE ALL| | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
    | 3 | TABLE ACCESS FULL | TRACE_BUSINESS_AREA | 10M| 4224M| 275K (2)| 00:55:01 | 1 | 6 |
    How does one correct the explain plan?
    The problem: Queries against the table are taking hours to complete. The problem started when the table was dropped then recreated with a new partition.
    I have complete the drop and creation against several tables for several years without problems until now.
    I have done the following: Analyzed statistics against the table, flushed buffer cache. Created a materialized view.
    However users queries are taking several hours to complete, where before the addition of the partition the queries where taking 5 minutes to complete.
    Thanks. BL.

    Yes, complete analysis of statistic was complete on indexes and against partitions.
    Table creation statement:
    CREATE TABLE TRACESALES.TRACE_BUSINESS_AREA
    ... *(400 columns)*
    TABLESPACE "trace_OLAPTS"
    PCTUSED 0
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL KEEP
    PARTITION BY RANGE (YEAR)
    PARTITION TRACE_06 VALUES LESS THAN ('2007')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2006
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_07 VALUES LESS THAN ('2008')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2007
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_08 VALUES LESS THAN ('2009')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2008
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_09 VALUES LESS THAN ('2010')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2009
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_10 VALUES LESS THAN ('2011')
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2010
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    PARTITION TRACE_11 VALUES LESS THAN (MAXVALUE)
    NOLOGGING
    NOCOMPRESS
    TABLESPACE TRACE_2011
    PCTFREE 15
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 1M
    NEXT 1M
    MINEXTENTS 1
    MAXEXTENTS UNLIMITED
    PCTINCREASE 0
    BUFFER_POOL DEFAULT
    NOCOMPRESS
    CACHE
    PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
    MONITORING;
    *(index statements, constraints, triggers and security)*
    Table caching is on and running in parallel degree 4 instances 1.

  • SQL INDEX USAGE

    hi,
    I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
    SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
    But still it does not use the index.Please suggest me some advice on this?
    Thanks

    user589320 wrote:
    I have a procedure which took 15-20 minutes in the past to execute.Suddently it is taking 2 hours.When i examined i came to know that the sql statement is not using one of the index.I dropped the index and created it.The explain plan is generated but still the index is not being used.I forced the index usage by using the index hint
    SELECT /*+ INDEX(test_his test_hist_idx )*/ column 1.....
    I think you're going to have to post the entire text of your query if you want an answer, or people will simply be trying to guess what you've done wrong.
    Do you also have the full execution plan from before and after the change in performance ?
    If you do post the text, and plans, please use the 'code' tags to make the text readable.
    p.s. My shot in the dark guess, based on the text you've supplied, is that you've used the table name in the hint, rather than the table alias.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The temptation to form premature theories upon insufficient data is the bane of our profession."
    Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • CBO not picking the right execution plan

    Database: Oracle 9.2.0.6 EE
    OS:Solaris 9
    I am trying to tune a query that is generated via Siebel Analytics. I am seeing a behaviour which is puzzling me but hopefully would be 'elementary' for someone like JPL.
    The query is based on a total of 7 tables. If I comment out any 2 dimension tables, the query picks up the right index on the fact table. However, the moment I add another table to the query, the plan goes awry.
    The query with 5 tables is as below:
    select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1,
    T352305.DAY_DT as c2,
    case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  as c3,
    T352305.ROW_WID as c5
    from
                   W_PRODUCT_D T30955,
                   W_PRDATTRNM_D T44643,                         
                   W_DAY_D T352305,                 
                   W_ORDERITEM_F T30256,              
                   W_PRDATTR_D T40081                         
    where  ( T30955.ROW_WID = T44643.ROW_WID
    and T30256.LAST_UPD_DT_WID = T352305.ROW_WID
    and T30256.PROD_ATTRIB_WID = T40081.ROW_WID 
    and T30256.PROD_WID = T30955.ROW_WID
    and T30955.PROD_NAME = 'Mobile Subscription'
    and (case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M'))
    and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1
    group by
    T352305.ROW_WID, T352305.DAY_DT,
    case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end
    ;And the execution plan is as below:
    | Id  | Operation                        |  Name                | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                 |                      |   269 | 25824 | 18660   (3)|
    |   1 |  SORT GROUP BY                   |                      |   269 | 25824 | 18660   (3)|
    |   2 |   NESTED LOOPS                   |                      |   269 | 25824 | 18658   (3)|
    |   3 |    NESTED LOOPS                  |                      |  6826 |   579K|  4734   (3)|
    |   4 |     MERGE JOIN CARTESIAN         |                      |     8 |   544 |     6  (17)|
    |   5 |      NESTED LOOPS                |                      |     1 |    54 |     4  (25)|
    |   6 |       TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D          |     1 |    37 |     3  (34)|
    |*  7 |        INDEX RANGE SCAN          | W_PRODUCT_D_M2       |     1 |       |     2  (50)|
    |   8 |       TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D        |     1 |    17 |     2  (50)|
    |*  9 |        INDEX UNIQUE SCAN         | W_PRDATTRNM_D_P1     |     1 |       |            |
    |  10 |      BUFFER SORT                 |                      |     8 |   112 |     4   (0)|
    |  11 |       TABLE ACCESS BY INDEX ROWID| W_DAY_D              |     8 |   112 |     3  (34)|
    |* 12 |        INDEX RANGE SCAN          | W_DAY_D_M39          |     8 |       |     2  (50)|
    |  13 |     TABLE ACCESS BY INDEX ROWID  | W_ORDERITEM_F        |   849 | 16131 |   592   (3)|
    |* 14 |      INDEX RANGE SCAN            | W_ORDERITEM_F_INDX9  |   852 |       |     4  (25)|
    |* 15 |    INDEX RANGE SCAN              | W_PRDATTR_D_M29_T1   |     1 |     9 |     3  (34)|
    ----------------------------------------------------------------------------------------------Note how the dimension tables W_PRODUCT_D & W_DAY_D are joined using cartesian join before joining to the fact table W_ORDERITEM_F using the composite index 'W_ORDERITEM_F_INDX9'. This index consists of LAST_UPD_DT_WID, PROD_WID and ACTION_TYPE_WID, which are foreign keys to the dimension tables.
    Now if I add one more table to the query:
    select count(distinct decode( T30256.HEADER_FLG , 'N' , T30256.ROW_WID ) ) as c1,
                  T352305.DAY_DT as c2,
                   case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  as c3,
                   T30371.X_BT_DLR_GROUP as c4,
                   T352305.ROW_WID as c5
              from                W_PRODUCT_D T30955,
                   W_PRDATTRNM_D T44643,                         
                   W_DAY_D T352305,                 
                   W_ORDERITEM_F T30256,              
                   W_ORDER_D T30371,                                            
                   W_PRDATTR_D T40081                         
              where  ( T30955.ROW_WID = T44643.ROW_WID
              and T30256.LAST_UPD_DT_WID = T352305.ROW_WID
              and T30256.PROD_ATTRIB_WID = T40081.ROW_WID
              and T30256.PROD_WID = T30955.ROW_WID
              and T30256.ORDER_WID = T30371.ROW_WID
              and T30955.PROD_NAME = 'Mobile Subscription'
              and T30371.STATUS_CD = 'Complete'
              and T30371.ORDER_TYPE = 'Sales Order' 
              and (case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end  in ('BT150BB-18M', 'BT250BB-18M', 'BT50BB-18M', 'BT600BB-18M'))
              and T352305.DAY_DT between TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 7 and TO_DATE('2008-09-27' , 'YYYY-MM-DD') - 1
              group by T30371.X_BT_DLR_GROUP, T352305.ROW_WID, T352305.DAY_DT,
              case  when T44643.PRODUCT_CLASS_NAME = 'MobileSubscription' then T40081.ATTR15_CHAR_VAL else 'Unspecified' end;I have added a single table W_ORDER_D to the query, and the execution plan is:
    | Id  | Operation                          |  Name               | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT                   |                     |    44 |  6336 | 78695   (3)|
    |   1 |  SORT GROUP BY                     |                     |    44 |  6336 | 78695   (3)|
    |   2 |   NESTED LOOPS                     |                     |    44 |  6336 | 78694   (3)|
    |   3 |    NESTED LOOPS                    |                     |   269 | 27707 | 78145   (3)|
    |*  4 |     HASH JOIN                      |                     |  6826 |   626K| 64221   (3)|
    |   5 |      TABLE ACCESS BY INDEX ROWID   | W_DAY_D             |     8 |   112 |     4  (25)|
    |*  6 |       INDEX RANGE SCAN             | W_DAY_D_M39         |     1 |       |     3  (34)|
    |   7 |      TABLE ACCESS BY INDEX ROWID   | W_ORDERITEM_F       | 86886 |  2206K| 64197   (3)|
    |   8 |       NESTED LOOPS                 |                     | 87004 |  6797K| 64200   (3)|
    |   9 |        NESTED LOOPS                |                     |     1 |    54 |     4  (25)|
    |  10 |         TABLE ACCESS BY INDEX ROWID| W_PRODUCT_D         |     1 |    37 |     3  (34)|
    |* 11 |          INDEX RANGE SCAN          | W_PRODUCT_D_M2      |     1 |       |     2  (50)|
    |  12 |         TABLE ACCESS BY INDEX ROWID| W_PRDATTRNM_D       |     1 |    17 |     2  (50)|
    |* 13 |          INDEX UNIQUE SCAN         | W_PRDATTRNM_D_P1    |     1 |       |            |
    |* 14 |        INDEX RANGE SCAN            | W_ORDERITEM_F_N6    | 86886 |       |   212  (18)|
    |* 15 |     INDEX RANGE SCAN               | W_PRDATTR_D_M29_T1  |     1 |     9 |     3  (34)|
    |* 16 |    INDEX RANGE SCAN                | W_ORDER_D_N6        |     1 |    41 |     3  (34)|
    -----------------------------------------------------------------------------------------------Now CBO doesn't choose the composite index and the cost also has increased to 78695. But if I simply add an /*+ORDERED*/ hint to the above query, so that it should join the dimension tables before joining to fact table, then the cost drops to 20913. This means that CBO is not choosing the plan with the lowest cost. I tried increasing the optimizer_max_permutations to 80000, setting session level optimizer_dynamic_sampling to 8 (just to see if it works), but no success.
    Could you please advise how to overcome this problem?
    Many thanks.

    joshic wrote:
    Database: Oracle 9.2.0.6 EE
    OS:Solaris 9
    I am trying to tune a query that is generated via Siebel Analytics. I am seeing a behaviour which is puzzling me but hopefully would be 'elementary' for someone like JPL.
    The query is based on a total of 7 tables. If I comment out any 2 dimension tables, the query picks up the right index on the fact table. However, the moment I add another table to the query, the plan goes awry.
    I have added a single table W_ORDER_D to the query, and the execution plan is:
    Now CBO doesn't choose the composite index and the cost also has increased to 78695. But if I simply add an /*+ORDERED*/ hint to the above query, so that it should join the dimension tables before joining to fact table, then the cost drops to 20913. This means that CBO is not choosing the plan with the lowest cost. I tried increasing the optimizer_max_permutations to 80000, setting session level optimizer_dynamic_sampling to 8 (just to see if it works), but no success.Back to the original question:
    * Can you force the index usage of the composite index on W_ORDERITEM_F in the second query using an INDEX hint (instead of the ORDERED hint)? If yes, what does the plan look like, particularly what cost is reported?
    * Could you post the plans including the "Predicate Information" section below the plan output?
    * What is the definition of the index W_ORDERITEM_F_N6 on W_ORDERITEM_F?
    * Are the cardinalities reported in the execution plans close to reality or way off? The best way to verify this would be to run your query with SQL tracing enabled and generate a tkprof output. If you do so please post the tkprof output here as well.
    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/

  • Worst execution plan ever?

    World record estimation fail.  We expect 1 row back, Sql Server expects over 23 trillion!  The estimated memory is 111 Petabytes (yes, I said Peta).
    We're using a pretty ugly view.  Ugly because it has nested views, a correlated subquery and about 20 total joins.  On the good side, the call is restricting the view with a single ID against the base table (this is for a single patient).  The
    rest of the view goes out and gets the patient's address, phone, contacts, status, insurance, diagnosis, etc.  The db structure is fairly normalized so that does include about 20 tables.
    This is a new application and as such there isn't much data yet.  When we run the view on our server with thousands of patients, the results are returned quickly.  Query time is subsecond.  The execution plan is ugly as expected, it's got
    hundreds of nodes, but the cost is pretty low and the performance is acceptable.
    When we run the same view on a disconnected device running Sql Server Localdb, it sometimes loses it's mind.  Note that the number of patients on the device is rarely over 100, it's a subset of the records on the server.  That's when we get the
    numbers that I'm quoting above.  Basically, the first join thinks there might be 12 records returns, then the next estimates 20 times that many, then 50 times that many, and that number just keeps multiplying until we get to trillions.
    I have a screenshot in case anyone thinks I'm exaggerating those numbers.  I also have the execution plan XML.  
    Bottom line is we're going to rewrite the query, but this now becomes an excuse to learn.  Where is Grant Fritchey when you need him?

    In situations like this, there are a few typical situations:
    The statistics are stale
    You are using parameters and parameter sniffing goes awry
    You've hit a bug or flaw in the optimizer
    The query can not be properly optimized
    The first possible situation is the easiest to find and fix. Simply run UPDATE STATISTICS (preferably WITH FULLSCAN) on each table that is part of the query.
    The second situation is also easily testable. For example, you can add OPTION WITH RECOMPILE (or any other relevant Compilation Option) to defeat parameter sniffing.
    Of course, you should always check whether you have proper indexes in place. Be aware that Foreign Key relations are not automatically indexed.
    If you are out of luck, and it is not any of the first two, then you can dive deeper and find out what is going wrong. If you lack the time or knowledge to do that, you can break the query in several queries and use temporary tables with intermediate results.
    Gert-Jan

  • Too many nested loops in execution plan?

    Hi,
    i wonder about execution plan not indicating that access to some tables (for join) is in parallel.
    Please see this example:
    ------------------------ snip ------------------------------------
    drop table test_a1;
    drop table test_a2;
    drop table test_b;
    drop table test_c;
    drop table test_d;
    create table test_a1 (
    x number,
    y number,
    z number);
    create unique index testa1_pk on test_a1 (x);
    create table test_a2 (
    x number,
    y number,
    z number);
    create unique index testa2_pk on test_a2 (x);
    create table test_b (
    x number,
    y number,
    z number);
    create unique index testb_pk on test_b (y);
    create table test_c (
    x number,
    y number,
    z number);
    create unique index testc_pk on test_b (z);
    create table test_d (
    x number,
    y number,
    z number);
    create unique index testd_pk on test_d (y);
    select
    a1.x a1_x,
    a1.y a1_y,
    a1.z a1_z,
    a2.x a2_x,
    a2.y a2_y,
    a2.z a2_z,
    b.x b_x,
    b.y b_y,
    b.z b_z,
    c.x c_x,
    c.y c_y,
    c.z c_z,
    d.x d_x,
    d.y d_y,
    d.z d_z
    from test_a1 a1, test_a2 a2, test_b b, test_c c, test_d d
    where a1.x = 100
    and a2.x = 200
    and b.y = a1.y
    and c.z = b.z
    and d.y = a1.y;
    ------------------------ snap ------------------------------------
    The execution plan goes like this:
    Select Stmt
         nested loops
              nested loops
                   nested loops
                        nested loops
                             table access
                                  index
                                       access predicate
                                            a2.x = 200
                             table access
                                  index
                                       access predicate
                                            a1.x = 100
                        table access
                             index
                                  access predicate
                                       d.y = a1.y
                   table access
                        index
                             access predicate
                                  b.y = a1.y
              table acess
                   index
                        acess predicate
                             c.z = b.z
    Access to tables a1 and a2 is on the same level (in parallel - i guess).
    However, why isn't access to table d and b on the same level?
    Both depend on a1. So no need to execute one after the other (no inter-dependency).
    Maybe i have just wrong expectation to the output of the execution plan(?!)
    - many thanks!
    best regards,
    Frank

    Preservation of identation and spacing is invaluable when it comes to reading an explain plan.
    | Id  | Operation                       | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                |           |     1 |   195 |     2   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS                   |           |     1 |   195 |     2   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS                  |           |     1 |   156 |     0   (0)| 00:00:01 |
    |   3 |    NESTED LOOPS                 |           |     1 |   117 |     0   (0)| 00:00:01 |
    |   4 |     NESTED LOOPS                |           |     1 |    78 |     0   (0)| 00:00:01 |
    |   5 |      TABLE ACCESS BY INDEX ROWID| TEST_A2   |     1 |    39 |     0   (0)| 00:00:01 |
    |*  6 |       INDEX UNIQUE SCAN         | TESTA2_PK |     1 |       |     0   (0)| 00:00:01 |
    |   7 |      TABLE ACCESS BY INDEX ROWID| TEST_A1   |     1 |    39 |     0   (0)| 00:00:01 |
    |*  8 |       INDEX UNIQUE SCAN         | TESTA1_PK |     1 |       |     0   (0)| 00:00:01 |
    |   9 |     TABLE ACCESS BY INDEX ROWID | TEST_D    |    82 |  3198 |     0   (0)| 00:00:01 |
    |* 10 |      INDEX UNIQUE SCAN          | TESTD_PK  |     1 |       |     0   (0)| 00:00:01 |
    |  11 |    TABLE ACCESS BY INDEX ROWID  | TEST_B    |    82 |  3198 |     0   (0)| 00:00:01 |
    |* 12 |     INDEX UNIQUE SCAN           | TESTB_PK  |     1 |       |     0   (0)| 00:00:01 |
    |* 13 |   TABLE ACCESS FULL             | TEST_C    |     1 |    39 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       6 - access("A2"."X"=200)
       8 - access("A1"."X"=100)
      10 - access("D"."Y"="A1"."Y")
      12 - access("B"."Y"="A1"."Y")
      13 - filter("C"."Z"="B"."Z")
    Access to tables a1 and a2 is on the same level (in parallel - i guess).
    Maybe i have just wrong expectation to the output of the execution plan(?!)You guess wrong, there's nothing parallel going on here.
    Execution plan is a tree of parent-child operations.
    For example, the NESTED LOOP at operation 4 has two children @ 5 and 7.
    Both of these operations- 5 & 7 - have a single child operation.
    The execution tree starts with operation 6, using the TESTA2_PK index to identify rows where A2.X=100.
    From this list of rowids, we go to the table TEST_A2 operation 5.
    The rows from operation five feed into the NESTED LOOP - operation 4.
    For each of these rows, we go to TEST_A1 via the index TEST_A1_PK for rows where A1.X=100.
    This is really a cartesian join because there's no join condition between the two tables.
    etc, etc, etc
    Three things in particular to point out.
    Firstly, that nothing joins to A2. So there will be a cartesian product - i.e. for every row in the result set between the joined tables A1, B, C and D, these will be multiplied by the number of rows returned by the the A2 rowsource.
    Secondly, when everything has got one or zero rows (or the optimizer thinks that it's one or zero rows), you can get very different plans from when there are known/thought to be more rows.
    Both depend on a1. So no need to execute one after the other (no inter-dependency).Thirdly, in terms of isolated join operations (ignoring A2 and C for the moment), A1 cannot join to B and D at the same time, you can either join A1 to B and then join the result of that to D, or join A1 to D then B, which is what you've got in your plan (well, actually we have A2 joined to A1 then the result of that joined to D and then the result of that to B).
    Edited by: Dom Brooks on Jul 6, 2011 4:07 PM
    Corrected typo

  • Query uses wrong index

    Hi,
    I have exported and imported two schemas to a different server. Now when a user fires a select query it takes more time than before. When I saw the execution plan for some of 'select' queries,I found that the queries are using wrong index.This is the reason for the delayed reponse time.
    Can anybody tell me why it happened ?
    Now what should I do?
    Can I force select query to use the right index?
    Thanx in advance

    Please find below details of the query and indexes. Do let me know if you need more information.
    Query:
    SELECT ROWID, warehouse_code, branch_code, client_code, job_srnum,
    department, inventory_date, file_no, client_carton_no, description,
    ref1, ref2, ref3, destruction_date, subject, pnw_carton_no,
    cre_user_id, cre_dt, upd_user_id, branch, upd_dt, status, date1,
    date2, num1, carton_size, addendum_date
    FROM ISTORET.rmst_inventory_details2
    WHERE branch_code = 'BOM'
    AND job_srnum = '62100113476'
    AND client_carton_no = 'BM4060394822'
    AND subject = 'FILES'
    ORDER BY file_no
    Execution Plan:
    Operation Object Name Rows Bytes Cost
    SELECT STATEMENT Optimizer Mode=CHOOSE 1 15
    SORT ORDER BY 1 155 15
    TABLE ACCESS BY INDEX ROWID ISTORET.RMST_INVENTORY_DETAILS2 1 155 5
    INDEX RANGE SCAN ISTORET.BRC_JOB_SUB_REF123_INDX 1 4
    Query time: More than 5 mins
    Same query with hint /*+ index(rmst_inventory_details2 BRC_JOB_CTN_FILE_INDX) */
    SELECT STATEMENT Optimizer Mode=CHOOSE 1 6
    TABLE ACCESS BY INDEX ROWID ISTORET.RMST_INVENTORY_DETAILS2 1 155 6
    INDEX RANGE SCAN ISTORET.BRC_JOB_CTN_FILE_INDX 1 5
    Query time: 110 msecs
    Index details:
    PARAMETER INDEX- 1 INDEX- 2
    Table Owner ISTORET ISTORET
    Table Name RMST_INVENTORY_DETAILS2 RMST_INVENTORY_DETAILS2
    Index Name BRC_JOB_CTN_FILE_INDX BRC_JOB_SUB_REF123_INDX
    Uniqueness NONUNIQUE NONUNIQUE
    Columns BRANCH_CODE
    JOB_SRNUM
    CLIENT_CARTON_NO
    FILE_NO BRANCH_CODE
    JOB_SRNUM
    SUBJECT
    REF1
    REF2
    REF3
    Table Type TABLE TABLE
    Status VALID VALID
    Tablespace ISTORET_RID2_INDX ISTORET_RID2_INDX
    Initial Extent Size 4,194,304 4,194,304
    Next Extent Size 4,194,304 4,194,304
    Minimum Extents 1 1
    Maximum Extents 2,147,483,645 2,147,483,645
    Percent Increase 0 0
    Distinct Keys 42,576,227 27,318,132
    Percent Free 10 10
    Index Type NORMAL NORMAL
    Partitioned No No
    Temporary No No
    Join Index No No
    Size in MB 2,456 2,140
    Number Extents 614 535
    Size in bytes 2,575,302,656 2,243,952,640
    Last Analyzed 20/3/2007 20/3/2007

  • Different execution plan for same query but for different condition value

    Hi All,
    I'm facing a strange situation where same query for different condition not working.
    1--
    Select  top 10 * from revenuefact(nolock) 
    where feecode ='OW4'
    2--
    Select  top 10 * from revenuefact(nolock)
    where feecode ='BTE'
    1st query is returning result easily but 2nd query is taking too long. Column
    feecode has already Non-clustered index and Clustered index is also available for another col RevenueSID.
    I was surprised when checked the query execution plan for both the above queries  which is quite different (as per attached below). Can anyone suggest me the reason behind it.
    And solution for the same. One more thing that data for feecode BTE is inserting through different source instead of others feecode and table contains more than 300 million rows.

    When I speak with people inside Microsoft who work with the optimizer, the refuse to accept the work "bug" when a query produces the correct result, but with a suboptimal plan. They prefer to use the word "limitation".
    The limitation here is that when the optimizer compares two plans, it only looks at the estimated cost. As far as I know, it does not perform any analysis from the perspective "what if the statistics are wrong"? They do provide the hint OPTIMIZE
    FOR UNKNOWN, but that does not work then there is a constant as in this case.
    The optimizer will surely distinguish between TOP 10 and TOP 10000000. With the latter, you have all reason to expect a Clustered Index Scan no matter which value you search for - unless you pick a value for which the histogram indicates that there are no
    rows.
    Interesting enough, I was able to reproduce the situation in my Northgale database, which is an inflated version of Northwind, and where statistics should be accurate.
    SELECT TOP 10 * FROM Orders WHERE EmployeeID = 8
    results in a CI scan, and so does also EmployeeID = 7, and even 5. There are only 2292 rows out of a total of 344305 rows. If I try EmployeeID 808 for which there are 1797, the optimizer goes for the index seek.
    Erland Sommarskog, SQL Server MVP, [email protected]

  • Help in TKPROF Output: Row Source Operation v.s Execution plan confusing

    Hello,
    Working with oracle 10g/widnows, and trying to understand from the TKPROF what is the purpose of the "Row Source operation" section.
    From the "Row Source Operation" section the PMS_ROOM table is showing 16 rows selected, and accessed by an ACCESS FULL, and the following script gives another value.
    select count(*) from pms_folio give the following.
    COUNT(*)
    148184
    But in the execution plan section, the PMS_FOLIO table is accessed by ROW ID after index scan in the JIE_BITMAP_CONVERSION index
    What really means Row Source operation compares to the execution plan and how both information should be read to fully know if the optimizer is not making wrong estimation?
    furthermore readding 13594 buffers to fetch 2 rows, show the SQL Script itself is not sufficient, but the elapsed time is roughly 0.7seconds,but shrinking the # of buffers to be read should probably shrink the response time.
    The following TKPROF output.
    Thanks very much for your help
    SELECT NVL(SUM(NVL(t1.TOTAL_GUESTS, 0)), 0)
    FROM DEV.PMS_FOLIO t1
    WHERE (t1.FOLIO_STATUS <> 'CANCEL'
    AND t1.ARRIVAL_DATE <= TO_DATE(:1, 'SYYYY/MMDDHH24MISS')
    AND t1.DEPARTURE_DATE > TO_DATE(:1, 'SYYYY/MMDDHH24MISS')
    AND t1.PRIMARY_OR_SHARE = 'P' AND t1.IS_HOUSE = 'N')
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 0.12 0.12 0 13594 0 2
    total 5 0.12 0.12 0 13594 0 2
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 82 (PMS5000)
    Rows Row Source Operation
    2 SORT AGGREGATE (cr=13594 pr=0 pw=0 time=120165 us)
    16 TABLE ACCESS FULL PMS_FOLIO (cr=13594 pr=0 pw=0 time=121338 us)
    Rows Execution Plan
    0 SELECT STATEMENT MODE: ALL_ROWS
    2 SORT (AGGREGATE)
    16 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PMS_FOLIO'
    (TABLE)
    0 INDEX MODE: ANALYZED (RANGE SCAN) OF
    'JIE_BITMAP_CONVERSION' (INDEX)
    <Edited by: user552326 on 8-Apr-2009 12:49 PM
    Edited by: user552326 on 8-Apr-2009 12:52 PM
    Edited by: user552326 on 8-Apr-2009 12:53 PM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    Your query is using bind variables. Explain Plan doesn't work exactly the same way -- it can't handle bind variables.
    See http://www.oracle.com/technology/oramag/oracle/08-jan/o18asktom.html
    In your output, the row source operations listing is the real execution.
    The explain plan listing may well be misleading as Oracle uses cardinality estimates when trying to explain with bind variables.
    Also, it seems that your plan table may be a 9i version, not the 10g PLAN_TABLE created by catplan.sql There are additional columns in the 10g PLAN_TABLE that explain uses well.
    BTW, you start off with a mention of "PMS_ROOM" showing 16 rows, but it doesn't appear in the data you have presented.

  • Why is my query using the wrong index?

    Hi SQL Tuning experts....
    I'm running Oracle 11.2.0.2 EE on Solaris 10
    I've just checked my top SQL statements in OEM and drilling down on the top query of the list, I decided to run SQL Advisor on the query.
    Low and behold, it came back with a profile that gives me a 99.9% improvement.
    When I compared the original plan to the new plan the only difference is that the SQL Advisor is using a different index.
    Now, the dumb DBA question: why? why is Oracle picking the wrong index?
    original plan
    SELECT STATEMENT
      COUNT STOPKEY
        VIEW
          SORT ORDER BY STOPKEY          
            TABLE ACCESS BY INDEX ROWID     ARADMIN.T2179          TABLE
              INDEX RANGE SCAN          ARADMIN.T2179_C3     INDEXnew plan...
    SELECT STATEMENT
      COUNT STOPKEY
        VIEW
          SORT ORDER BY STOPKEY          
            TABLE ACCESS BY INDEX ROWID     ARADMIN.T2179               TABLE
              INDEX RANGE SCAN          ARADMIN.T2179_C536870923     INDEXThe stats:
    table has approx. 3.3Mil rows
    table segment is approx. 15G (5G of it is reclaimable space, but probably not related)
    table has fresh stats and indexes have been recently rebuilt
    indexes in this discussion are both b-tree
    the C3 column is number(15) with 2836897 distinct rows
    the C536870923 columns is VARCHAR2(255) with 1080533 distinct values
    Here is the actual query:
         SELECT *
    FROM (
    SELECT T2179.C1,C536871040,C536871037,C536870944,C3,C536870918,C536870919,
    C536870924,C536871048,C536871049,C536871050,C536870926,C536870925,
    C536870916,C4,C536871275,C536871095,C536870913
    FROM T2179
    WHERE ((T2179.C536870923 = :"SYS_B_0") AND (T2179.C3 > :"SYS_B_1")) ORDER BY C1 DESC )
    WHERE ROWNUM <= :"SYS_B_2"Obviously this is a good example of why we should use profiles. :-)
    Edited by: ji li on Feb 14, 2013 1:32 PM
    Sorry... I should have included the plan output
    I'm guessing this has something to do with the cardinality of the data in the columns.

    Dom.... I've already posted most everything. Here are the relevant init params and misc stuff you are asking for.
    NAME                                 TYPE                             VALUE
    object_cache_optimal_size            integer                          102400
    optimizer_capture_sql_plan_baselines boolean                          FALSE
    optimizer_dynamic_sampling           integer                          2
    optimizer_features_enable            string                           11.2.0.2
    optimizer_index_caching              integer                          0
    optimizer_index_cost_adj             integer                          100
    optimizer_mode                       string                           ALL_ROWS
    optimizer_secure_view_merging        boolean                          TRUE
    optimizer_use_invisible_indexes      boolean                          FALSE
    optimizer_use_pending_statistics     boolean                          FALSE
    optimizer_use_sql_plan_baselines     boolean                          TRUE
    plsql_optimize_level                 integer                          2
    db_file_multiblock_read_count        integer                          128
    db_block_size                        integer                          8192
    cursor_sharing                       string                           FORCE
    SNAME                          PNAME                                    PVAL1 PVAL2
    SYSSTATS_INFO                  STATUS                                         COMPLETED
    SYSSTATS_INFO                  DSTART                                         12-04-2012 12:28
    SYSSTATS_INFO                  DSTOP                                          12-04-2012 15:28
    SYSSTATS_INFO                  FLAGS                                        0
    SYSSTATS_MAIN                  CPUSPEEDNW                     2992.2746781116
    SYSSTATS_MAIN                  IOSEEKTIM                                   10
    SYSSTATS_MAIN                  IOTFRSPEED                                4096
    SYSSTATS_MAIN                  SREADTIM                             48027.271
    SYSSTATS_MAIN                  MREADTIM                             37217.102
    SYSSTATS_MAIN                  CPUSPEED                                  2978
    SYSSTATS_MAIN                  MBRC                                         0
    SYSSTATS_MAIN                  MAXTHR                               400782336
    SYSSTATS_MAIN                  SLAVETHR                               1403904
    13 rows selected.
    QL> l
      1  SELECT * FROM (
      2    SELECT
      3    T2179.C1,
      4    C536871040,
      5    C536871037,
      6    C536870944,
      7    C3,
      8    C536870918,
      9    C536870919,
    10    C536870924,
    11    C536871048,
    12    C536871049,
    13    C536871050,
    14    C536870926,
    15    C536870925,
    16    C536870916,
    17    C4,
    18    C536871275,
    19    C536871095,
    20    C536870913
    21    FROM aradmin.T2179
    22    WHERE (
    23     (C536870923 = '300885690')
    24    AND
    25     (C3 > '1360938353')
    26          )
    27    ORDER BY C1 DESC )
    28* WHERE ROWNUM <= 1
    no rows selected
    Elapsed: 00:00:00.01
    Execution Plan
    Plan hash value: 2768254526
    | Id  | Operation                      | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT               |          |     1 |  2315 |     6  (17)| 00:00:01 |
    |*  1 |  COUNT STOPKEY                 |          |       |       |            |          |
    |   2 |   VIEW                         |          |     1 |  2315 |     6  (17)| 00:00:01 |
    |*  3 |    SORT ORDER BY STOPKEY       |          |     1 |   226 |     6  (17)| 00:00:01 |
    |*  4 |     TABLE ACCESS BY INDEX ROWID| T2179    |     1 |   226 |     5   (0)| 00:00:01 |
    |*  5 |      INDEX RANGE SCAN          | T2179_C3 |     1 |       |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM<=1)
       3 - filter(ROWNUM<=1)
       4 - filter("C536870923"='300885690')
       5 - access(SYS_OP_DESCEND("C3")<HEXTORAW('3AF1C2A1ABC9FF') )
           filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("C3"))>1360938353)
    Statistics
              0  recursive calls
              0  db block gets
           2615  consistent gets
              0  physical reads
              0  redo size
           1538  bytes sent via SQL*Net to client
            513  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
              0  rows processed

  • Force statement to use a given rule or execution plan

    Hi!
    We have a statement that in our production system takes 6-7 seconds to complete. The statement comes from our enterprise application's core code and we are not able to change the statement.
    When using a RULE-hint (SELECT /*+RULE*/ 0 pay_rec...........) for this statement, the execution time is down to 500 milliseconds.
    My question is: Is there any way to pin a execution plan to a given statement. I have started reading about outlines, which seems promising. However, the statement is not using bind-variables, and since this is core code in an enterprise application I cannot change that either. Is it possible to use outlines with such a statement?
    Additional information:
    When I remove all statistics for the involved tables, the query blows away in 500 ms.
    The table tran_info_types has 61 rows and is a stable table with few updates
    The table ab_tran_info has 1 717 439 records and is 62 MB in size.
    The table query_result has 777 015 records and is 216 MB in size. This table is constantly updated/insterted/deleted.
    The query below return 0 records as there is no hits in the table query_result.
    This is the statement:
    SELECT  /*+ALL_ROWS*/
           0 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334549
       AND qr2.unique_id = 5334550
    UNION ALL
    SELECT 1 pay_rec, abi.tran_num, abi.type_id, abi.VALUE
      FROM ab_tran_info abi,
           tran_info_types ti,
           query_result qr1,
           query_result qr2
    WHERE abi.tran_num = qr1.query_result
       AND abi.type_id = qr2.query_result
       AND abi.type_id = ti.type_id
       AND ti.ins_or_tran = 0
       AND qr1.unique_id = 5334551
       AND qr2.unique_id = 5334552;Here is the explain plan with statistics:
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 900  Bytes: 82  Cardinality: 2                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   5 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        3 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             1 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            
              14 NESTED LOOPS  Cost: 450  Bytes: 41  Cardinality: 1                 
                   12 NESTED LOOPS  Cost: 449  Bytes: 1,787,940  Cardinality: 59,598            
                        10 NESTED LOOPS  Cost: 448  Bytes: 19,514,824  Cardinality: 1,027,096       
                             8 INDEX RANGE SCAN UNIQUE TRADEDB.TIT_DANIEL_2 Search Columns: 1  Cost: 1  Bytes: 155  Cardinality: 31 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_7 Search Columns: 1  Cost: 48  Bytes: 471,450  Cardinality: 33,675 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 11  Cardinality: 1            Here is the execution plan when I have removed all statistics (exec DBMS_STATS.DELETE_TABLE_STATS(.........,..........); )
    Plan
    SELECT STATEMENT  HINT: ALL_ROWSCost: 12  Bytes: 3,728  Cardinality: 16                           
         15 UNION-ALL                      
              7 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   5 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        3 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             1 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             2 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        4 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   6 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            
              14 NESTED LOOPS  Cost: 6  Bytes: 1,864  Cardinality: 8                 
                   12 NESTED LOOPS  Cost: 6  Bytes: 45,540  Cardinality: 220            
                        10 NESTED LOOPS  Cost: 6  Bytes: 1,145,187  Cardinality: 6,327       
                             8 TABLE ACCESS FULL TRADEDB.TRAN_INFO_TYPES Cost: 2  Bytes: 104  Cardinality: 4 
                             9 INDEX RANGE SCAN UNIQUE TRADEDB.ATI_DANIEL_6 Search Columns: 1  Cost: 1  Bytes: 239,785  Cardinality: 1,547 
                        11 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1       
                   13 INDEX UNIQUE SCAN UNIQUE TRADEDB.QUERY_RESULT_INDEX Search Columns: 2  Bytes: 26  Cardinality: 1            Our Oracle 9.2 database is set up with ALL_ROWS.
    Outlines: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/outlines.htm#13091
    Cursor sharing: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3696883368520

    Hi!
    We are on Oracle 9iR2, running on 64-bit Linux.
    We are going to upgrade to Oracle 10gR2 in some months. Oracle 11g is not an option for us as our application is not certified by our vendor to run on that version.
    However, our performance problems are urgent so we are looking for a solution before we upgrade as we are not able to upgrade before we have done extensive testing which takes 2-3 months.
    We have more problem sql's than the one shown in this post. I am using the above SQL as a sample as I think we can solve many other slow running SQL's if we solve this one.
    Is the SQL Plan management an option on Oracle 9i and/or Oracle 10g?

  • Index usage error

    i am having a table in my schema named provider_rate_history
    PROVIDER_RATE_HISTORY_ID      NOT NULL      NUMBER
    WORK_ORDER_HISTORY_ID      NOT NULL      NUMBER
    PROVIDER_RATE_TYPE_ID      NOT NULL      NUMBER
    CREATED_BY      NOT NULL      NUMBER
    DATE_CREATED      NOT NULL      DATE
    MODIFIED_BY           NUMBER
    DATE_MODIFIED           DATE
    I created an index named provider_rate_type_idx on the provider_rate_type_id column of the table, but when i am using the following query index is used, but if i replace count(*) keyword in the select statement with any of the column name of the table a ful table scan is performed. What could be the reason for this error and how to correct it
    select count(*) from provider_rate_history
    where rate_type_id=7;
    Index is used, if we replace count(*) with any column name of the table index is not used
    select work_order_history_id from provider_rate_history
    where rate_type_id=7;
    Index is not used

    Hi,
    Why count(*) will lead to full table scan?
    APC have clearly told reason for not using Index.
    Hope this illustration helps to clear the situation.
    SQL> create table test111 as select * from all_objects where rownum < 1001;
    Table created.
    SQL> desc test111
    Name Null? Type
    OWNER NOT NULL VARCHAR2(30)
    OBJECT_NAME NOT NULL VARCHAR2(30)
    SUBOBJECT_NAME VARCHAR2(30)
    OBJECT_ID NOT NULL NUMBER
    DATA_OBJECT_ID NUMBER
    OBJECT_TYPE VARCHAR2(19)
    CREATED NOT NULL DATE
    LAST_DDL_TIME NOT NULL DATE
    TIMESTAMP VARCHAR2(19)
    STATUS VARCHAR2(7)
    TEMPORARY VARCHAR2(1)
    GENERATED VARCHAR2(1)
    SECONDARY VARCHAR2(1)
    SQL> create index test111_indx1 on test111 (object_id);
    Index created.
    SQL>
    SQL> set autotrace on
    SQL> select count(1) from test111;
    COUNT(1)
    1000
    Execution Plan
    Plan hash value: 1326770390
    | Id | Operation | Name | Rows | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 3 (0)| 00:00:01 |
    | 1 | SORT AGGREGATE | | 1 | | |
    | 2 | INDEX FAST FULL SCAN| TEST111_INDX1 | 1000 | 3 (0)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    5 recursive calls
    0 db block gets
    23 consistent gets
    3 physical reads
    0 redo size
    206 bytes sent via SQL*Net to client
    239 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed
    SQL>
    SQL> select count(distinct owner) from test111;
    COUNT(DISTINCTOWNER)
    3
    Execution Plan
    Plan hash value: 991123090
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 17 | 5 (0)| 00:00:01 |
    | 1 | SORT GROUP BY | | 1 | 17 | | |
    | 2 | TABLE ACCESS FULL| TEST111 | 1000 | 17000 | 5 (0)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    Statistics
    27 recursive calls
    0 db block gets
    33 consistent gets
    0 physical reads
    0 redo size
    233 bytes sent via SQL*Net to client
    239 bytes received via SQL*Net from client
    2 SQL*Net roundtrips to/from client
    1 sorts (memory)
    0 sorts (disk)
    1 rows processed
    SQL>

  • Index Usage

    Hi All,
    Using Oracle 11.2.0.3 on a TEST server
    create index emp_job_sal_idx on emp(job,sal) ;
    SQL> create or replace view test1 as select d.deptno, d.dname, e.empno, e.job, e.sal from dept d, emp e where d.deptno=e.deptno and
    (e.job='CLERK' and e.sal > 1000) OR
    (e.job='ANALYST' and e.sal >= 3000) OR
    (e.job='SALESMAN' and e.sal >=1500);
    SQL> set autotrace on explain
    SQL> select * from test1;
    18 rows selected.
    Execution Plan
    Plan hash value: 4192419542
    | Id  | Operation        | Name | Rows  | Bytes | Cost (%CPU)| Time       |
    |   0 | SELECT STATEMENT   |       |     1 |    67 |    10   (0)| 00:00:01 |
    |   1 |  NESTED LOOPS        |       |     1 |    67 |    10   (0)| 00:00:01 |
    |   2 |   TABLE ACCESS FULL| DEPT |     4 |    88 |     3   (0)| 00:00:01 |
    |*  3 |   TABLE ACCESS FULL| EMP  |     1 |    45 |     2   (0)| 00:00:01 |
    ---------------------------------------------------------------------------The index is not used, mostly due to a OR condition. How can we make the index use without using hints ?

    sb92075 wrote:
    post EXPLAIN PLAN for problem SQL
    Execution Plan
    Plan hash value: 3466901445
    | Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |             |     1 |   331 |   383K  (7)| 01:16:40 |
    |*  1 |  HASH JOIN         |             |     1 |   331 |   383K  (7)| 01:16:40 |
    |*  2 |   TABLE ACCESS FULL| ENT_TRAN|     1 |   165 |   205K  (9)| 00:41:07 |
    |   3 |   TABLE ACCESS FULL| ENT_MAST         |    19M|  3111M|   177K  (3)| 00:35:31 |
    1 - access(NLSSORT("ENT_MAST"."ID",'nls_sort=''BINARY_CI''')=NLSSORT(
                  "ENT_TRAN"."RID",'nls_sort=''BINARY_CI'''))
       2 - filter(NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'''
                  )=HEXTORAW('616D616E616820736168616D206E6173696F6E616C2062657268616400')
                  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('343
                  73435377600')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_C
                  I''')=HEXTORAW('74656E616761206E6173696F6E616C2062657268616400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3230303
                  836367700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('74656C656B6F6D206D616C61797369612062657268616400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3132383
                  734307000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6167726F2062616E6B00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3831313
                  831307500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6272756365206C656520796565206C616D00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3530333
                  333373100')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('616B6261722074726164696E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030313
                  438383037397500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('372D656C6576656E206D616C61797369612073646E2062686400')
                    AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
                  132303936327000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('6368616E20796F6B65206368656E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
                  532372D30362D3534393600')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('646B7368206D616C61797369612073646E2062686400')
                    AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3
                  030343437367500')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('626574746572207B267D206265737420656E746572707269736500
                  ')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
                  '3030313632353132347000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('6C696D20656E672073696F65206A756E6B657400')
                  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('743
                  5353138393300')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY
                  _CI''')=HEXTORAW('712E712E206A756E6B657400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('7331373
                  233363200')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI'
                  '')=HEXTORAW('6572206B696D206B656F6E6700')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3539303
                  932302D31302D3538333700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('726963686C616E64206C6569737572652067726F757000
                  ')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW(
                  '3538303532382D30312D3539383500')  OR
                  NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('74
                  69656E2079756E20656E74657270726973652073646E2E206268642E00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3637303
                  332382D31302D3534363700')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sor
                  t=''BINARY_CI''')=HEXTORAW('73686172696B617420686F636B2068696E00')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3030303
                  234323136397000')  OR NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINA
                  RY_CI''')=HEXTORAW('6D7964696E206D6F68616D656420686F6C64696E67732062686420
                  28666F726D65726C79206B6E6F776E206173206D7964696E206D6F68616D656420686F6C64
                  696E67732073646E206268642900')  AND NLSSORT("ENT_TRAN"."PP_NO",'nls_so
                  rt=''BINARY_CI''')=HEXTORAW('3232313434386100')  OR
                  NLSSORT("ENT_TRAN"."NAME",'nls_sort=''BINARY_CI''')=HEXTORAW('65
                  7665726973652076656E74757265732073646E2062686400')  AND
                  NLSSORT("ENT_TRAN"."PP_NO",'nls_sort=''BINARY_CI''')=HEXTORAW('3239353
                  137377000')  OR NLSSORT("EN)
    Statistics
              1  recursive calls
              0  db block gets
        1353887  consistent gets
        1353339  physical reads
              0  redo size
        1204784  bytes sent via SQL*Net to client
           4989  bytes received via SQL*Net from client
            408  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
           6092  rows processed
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Index usage in depending on where clause changes.

    Hello Friends,
    I need your help for one issue.
    I have one query , which is using two table Say T1 and T2, where C1 is common column using which both are joined.
    C1 is primary key in T1, but no index available in T2 for C1. T1C2 is the column which we want to select.
    (Note that Either of table can be a Master table)
    Now see the query:
    Select T1C2
    From T1, T2
    where T2.C1 = T1.C1
    Here where clause may have other conditions and From clause may have others tables as per requirements.
    I want to know that, if, I change the query like following to let my query use the available index of T1.C1.
    Select T1C2
    from T1, T2
    where T1.C1 = T2.C1
    Then, Will the query use the available index of T1. and Will i get better performance. Even a little improvement in performance may help me a lot as this kind of query is being used within a where loop (so it is going to be executed multiple times).
    Please advise on this..
    Regards,
    Dipali..

    Hi,
    18:43:17 rel15_real_p>create table t1(c1 number primary key, c2 number);
    Table created.
    18:43:26 rel15_real_p>create table t2(c1 number, c2 number);
    18:45:08 rel15_real_p>
    18:45:09 rel15_real_p>begin
    18:45:09   2  for i in 1..100
    18:45:09   3  loop
    18:45:09   4        insert into t1(c1,c2) values (i,i+100);
    18:45:09   5  end loop;
    18:45:09   6  commit;
    18:45:09   7  end;
    18:45:09   8  /
    PL/SQL procedure successfully completed.
    18:45:09 rel15_real_p>
    18:45:09 rel15_real_p>
    18:45:09 rel15_real_p>begin
    18:45:09   2  for i in 1..100
    18:45:09   3  loop
    18:45:09   4        insert into t2(c1,c2) values (i,i+200);
    18:45:09   5  end loop;
    18:45:09   6  commit;
    18:45:09   7  end;
    18:45:09   8  /
    18:45:23 rel15_real_p>select count(*) from t1;
      COUNT(*)
           100
    18:45:30 rel15_real_p>select count(*) from t2;
      COUNT(*)
           100
    18:45:49 rel15_real_p>select index_name,index_type from user_indexes where table
    _name='T1';
    INDEX_NAME                     INDEX_TYPE
    SYS_C0013059                   NORMAL
    18:48:21 rel15_real_p>set autotrace on
    18:52:25 rel15_real_p>Select T1.C2
    18:52:29   2  From T1, T2
    18:52:29   3  where T2.C1 = T1.C1
    18:52:29   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=100 Bytes=
              900)
       1    0   HASH JOIN (Cost=7 Card=100 Bytes=3900)
       2    1     TABLE ACCESS (FULL) OF 'T1' (TABLE) (Cost=3 Card=100 By
              es=2600)
       3    1     TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 By
              es=1300)
    Statistics
              0  recursive calls
              0  db block gets
             21  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
            100  rows processed
    18:52:31 rel15_real_p>analyze table t1 compute statistics;
    Table analyzed.
    18:55:35 rel15_real_p>analyze table t2 compute statistics;
    18:55:38 rel15_real_p>set autotrace on
    18:55:42 rel15_real_p>Select T1.C2
    18:55:43   2  From T1, T2
    18:55:45   3  where T2.C1 = T1.C1
    18:55:46   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
              00)
       1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
              rd=100 Bytes=500)
       3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
              Cost=1 Card=100)
       4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
       5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
              ytes=200)
    Statistics
              1  recursive calls
              0  db block gets
             23  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
            100  rows processed
    18:56:56 rel15_real_p>Select T1.C2
    18:56:56   2  From T1, T2
    18:56:56   3  where T1.C1 = T2.C1
    18:56:58   4  /
            C2
           101
           102
           103
           104
           105
            C2
           200
    100 rows selected.
    Execution Plan
       0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=100 Bytes=7
              00)
       1    0   MERGE JOIN (Cost=6 Card=100 Bytes=700)
       2    1     TABLE ACCESS (BY INDEX ROWID) OF 'T1' (TABLE) (Cost=2 Ca
              rd=100 Bytes=500)
       3    2       INDEX (FULL SCAN) OF 'SYS_C0013059' (INDEX (UNIQUE)) (
              Cost=1 Card=100)
       4    1     SORT (JOIN) (Cost=4 Card=100 Bytes=200)
       5    4       TABLE ACCESS (FULL) OF 'T2' (TABLE) (Cost=3 Card=100 B
              ytes=200)
    Statistics
              1  recursive calls
              0  db block gets
             23  consistent gets
              0  physical reads
              0  redo size
           1393  bytes sent via SQL*Net to client
            562  bytes received via SQL*Net from client
              8  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
            100  rows processed- Pavan Kumar N

Maybe you are looking for