Query is not using the INDEX

I have issue with a query as follows. It is not using index when i keep a function on the left hand side of comparison in where condition.
But when I remove the function it is using index.
With BLC AS
Name                                      Null?    Type
ID                                        NOT NULL NUMBER
MASTER_VALUE               NOT NULL NUMBER(8)
DESC_TEXT_ID                                    NUMBER
GVM                                                     VARCHAR2(50)
MASTER_LOOKUP_ID    NOT NULL  NUMBER
WORK_SECTION_ID                          NUMBER
AUDIT_TRAIL_NO                              NUMBER
SQL> SELECT COUNT(*) FROM BLC;
  COUNT(*)
      7769
SQL> SELECT COUNT(DISTINCT(GVM)) "distinct" FROM BLC;
  distinct
      1350
SQL> SELECT COUNT(*) "nulls" FROM BLC WHERE GVM IS NULL;
     nulls
      6419
SQL> SELECT COLUMN_NAME,INDEX_NAME FROM DBA_IND_COLUMNS WHERE TABLE_NAME='BLC';
COLUMN_NAME                              INDEX_NAME
MASTER_LOOKUP_ID      LKPCDE_MSTLKP_FK_I
WORK_SECTION_ID        LKPCDE_WRKSEC_FK_I
GVM                                   LKPCDE_UK
MASTER_VALUE              LKPCDE_MASTERID_VALUE_UK
MASTER_LOOKUP_ID     LKPCDE_MASTERID_VALUE_UK
ID                                       LKPCDE_PK
SQL> EXPLAIN PLAN FOR SELECT ID FROM BLC WHERE UPPER ( GVM) = 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3196655606
| Id  | Operation         | Name             | Rows  | Bytes | Cost (%CPU)| Time|
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT  |                  |    78 |   624 |    18   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| BLC |    78 |   624 |    18   (0)| 00:00:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER("GVM")='MAIN_ORG')
13 rows selected.
SQL> EXPLAIN PLAN FOR SELECT ID FROM BLC WHERE GVM
  = 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 1620245961
| Id  | Operation                   | Name             | Rows  | Bytes | Cost (%
CPU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT            |                  |     1 |     8 |     2
(0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| BLC |     1 |     8 |     2
(0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | LKPCDE_UK        |     1 |       |     1
(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   2 - access("GVM"='MAIN_ORG')
14 rows selected.
SQL> EXPLAIN PLAN FOR SELECT /* INDEX(LKPCDE_UK) */ ID FROM BLC WHE
RE UPPER ( GVM ) = 'MAIN_ORG';
Explained.
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3196655606
| Id  | Operation         | Name             | Rows  | Bytes | Cost (%CPU)| Time
     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT  |                  |    78 |   624 |    18   (0)| 00:0
0:01 |
|*  1 |  TABLE ACCESS FULL| BLC |    78 |   624 |    18   (0)| 00:0
0:01 |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   1 - filter(UPPER("GVM")='MAIN_ORG')
13 rows selected.
Please let me know how i can force to use an index as it is causing CPU usage.
I can not change the query in application as it is used at many places.
Thanks

Hi,
Version is
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for 64-bit Windows: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
Sorry, in my last post i forgot to mention that i already created a function based index but still it is not using because, there is a UNIQUE constraint on that column.
Thanks

Similar Messages

  • Query not using the index

    Query
    SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
    From PROD
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
         37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
              36 COUNT STOPKEY
                   35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
                        33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
                             31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
                                  28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
                                       26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
                                            24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
                                                 22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
                                                      19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
                                                           17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
                                                                14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
                                                                     12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
                                                                          1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                          11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
                                                                               2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                               10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
                                                                                    3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                    9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
                                                                                         4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                         8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
                                                                                              5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                     13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                     15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                           18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                           20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                 23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                            25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                       27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                  30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                       29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                             bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
                        34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    From DEV platform
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
         37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
              36 COUNT STOPKEY
                   35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
                        1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                        34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
                             2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                             33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
                                  3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                  32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
                                       4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                       31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
                                            29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
                                                 27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
                                                      24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
                                                           22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
                                                                20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
                                                                     18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
                                                                          15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
                                                                               13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
                                                                                    10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
                                                                                         8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
                                                                                              5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                                         9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                                    12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                                         11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                                               14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                          17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                                               16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                                     19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                           23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                                           25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                                       bold           28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
                                            30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    Conclusion:
    IND_PART_INFO2PART_NUM is not in use in Production environment
    PROD
    1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
    IND_PART_INFO2PART_NUM 103023 46488
    DEV environment
    SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
    IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
    1. Index is rebuild
    2. stats are up to date
    3. Redef on table is done.
    Still no change in the plan .

    Osama-mustafa wrote:
    Aman.... wrote:
    Osama-mustafa wrote:
    alter index <index-name> rebuild ;Why?
    Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
    Aman....

  • Why is this query not using the index?

    check out this query:-
    SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
    FROM TABLE1
    WHERE STATUS = 'N'
    and here's the explain plan:-
    1     
    2     -------------------------------------------------------------------------------------
    3     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    4     -------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
    6     |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
    7     -------------------------------------------------------------------------------------
    8     
    9     Predicate Information (identified by operation id):
    10     ---------------------------------------------------
    11     
    12     1 - filter("STATUS"='N')
    There is already an index on this column, as is shown below:-
         INDEX_NAME INDEX_TYPE     UNIQUENESS     TABLE_NAME     COLUMN_NAME     COLUMN_POSITION
    1     TABLE1_IDX2 NORMAL     NONUNIQUE     TABLE1      STATUS     1
    2     TABLE1_IDX NORMAL     NONUNIQUE     TABLE1     HEADER_ID     1
    So why is this query not using the index on the 'STATUS' Column?
    I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
    I have tried this command also:-
    exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
    inspite of this, the query is still using a full table scan.
    The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
    Please help.
    Edited by: user10047779 on Mar 16, 2010 6:55 AM

    If the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
    create table skewed_a_lot
    as
       select
          case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
          level as col1
       from dual connect by level <= 1000000;
    create index skewed_a_lot_i01 on skewed_a_lot (flag);
    exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example.

  • Why is Oracle not using the index??

    Hi,
    I have a table called 'arc_errors' which has an index on 'member_number' as follows:- Create/Recreate indexes
    create index DWO.DW_ARC_CERRORS_MNO on DWO.DW_ARC_CERRORS (MEMBER_NUMBER);
    But surpisingly, when I execute the following query, it does not use the index.
    SELECT member_number,
    COUNT(*) error_count
    FROM arc_errors a
    WHERE member_number = 68534152 AND
    ( tx_type = 'SDIC' AND
    error_number IN (4, 7, 12, 13, 15, 17, 18, 705) )
    OR
    ( tx_type = 'AUTH' AND
    error_number IN (100, 104, 107, 111, 116) )
    OR
    ( tx_type = 'BHO' AND
    error_number IN (708,710) )
    OR
    ( tx_type = 'XLGN' AND
    ( error_number BETWEEN 102 AND 105 OR
    error_number BETWEEN 107 AND 120 OR
    error_number BETWEEN 300 AND 304 ) )
    OR
    ( tx_type = 'None' AND
    ( error_number IN (20, 112) OR
    error_number BETWEEN 402 AND 421 ) )
    OR
    ( tx_type = 'HYBR' AND
    error_number IN (303, 304) )
    GROUP BY member_number;
    This is what 'explain plan' tell me
    SELECT STATEMENT, GOAL = RULE               237907     502923     15087690     
    SORT GROUP BY               237907     502923     15087690     
    PARTITION RANGE ALL                              
    TABLE ACCESS FULL     DWO     DW_ARC_CERRORS     237209     502923     15087690     
    Can someone tell me why a 'table acess full' is required here?
    Thanks in advance,
    Rajesh

    Sorry, I just found the solution myself. I need to put an extra pair of braces around the set of conditions seperated by OR.

  • Why does it not use the index?

    L.S.,
    We are using a table called IT_RFC_REGISTRATION. It is a relatively big table for our application.
    Its primary key is RFCNR, each new RFCNR getting the next value.
    Now for my intranet report I am interested in the last 40 records. But when I execute:
    SELECT *
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the query takes ages to execute.
    When I do this:
    SELECT RFCNR
    FROM IT_RFC_REGISTRATION
    ORDER BY RFCNR DESC
    the result comes instantaneous because this query uses the index on RFCNR.
    Why does the former query not use the index to execute? It should be much faster to fetch ROWIDs from the index end to start and use those to get the records, than to load all the records and then sort them.
    Is there a trick with which I can use a join of the latter query and the former query to speed up the result?
    Greetings,
    Philbert de Zwart,
    Utrecht, The Netherlands.

    The difference you see in query run time is based on the amount data being sorted, then returned. In the first query, a full table scan is faster since if the index was used, Oracle would have to do a lookup in the index, get the rowid's and go look up the data in the table (TWO disk i/o's). It's faster to just scan the entire table.
    Indexes will generally not be used unless you have a where clause. If you only need a few fields from the table, you could include them all in an index. For instance, if you only need RFCNR & DESC create a concatenated index on those two columns and then only a scan of the index is required (very fast).

  • Why my select is not using the index

    This is my index
    CREATE INDEX CONFIG_STATE_IDX ON IDENTIFIER
    (CONFIGURATION_ID, STATE)
    LOGGING
    TABLESPACE NII_INDEX
    PCTFREE 10
    INITRANS 2
    MAXTRANS 255
    STORAGE (
    INITIAL 64K
    MINEXTENTS 1
    MAXEXTENTS 2147483645
    PCTINCREASE 0
    FREELISTS 1
    FREELIST GROUPS 1
    BUFFER_POOL DEFAULT
    NOPARALLEL;
    This is my select statement:
    SELECT *
    FROM identifier i
    WHERE
         i.configuration_id = '89afead40a0c0b8d00628c59aa405ea4'
         AND i.state = 'QT'
    AND ROWNUM <6
    This is my exmplain plan result
    Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    SELECT STATEMENT Hint=CHOOSE          5           2128                     
    COUNT STOPKEY                                        
    TABLE ACCESS FULL     IDENTIFIER     133 K     19 M     2128                     
    Why it is not using the index on configuration_id and state.

    Possibility one: you didn't do an analyze statistics on the table and/or the index after index creation.
    Possibility two: The optimizer has determined that it can return the query result set with fewer I/Os if it does a FTS vs using the index (the optimizer is very keen on I/Os).

  • Simple SQL Query is not using Bitmap index

    Hello to All,
    We are having Oracle9i Database and using it for the datawarehouse purpose.
    I have created the bitmap index on calledinfo column and I am running the following simple query which takes serveral hours to complete:
    select * from ssp.ssp_2006_q4 where calledinfo='799992515f'
    OR
    select calledinfo from ssp.ssp_2006_q4 where calledinfo='799992515f'
    I don't know why it is not using the bitmap index: Can anybody help me here?
    Thanks in Advance
    Hashim

    I know why and everyone that has read Jonathan Lewis' book on the CBO knows why.
    Why? Because the CBO thinks the cost of using your index will be higher than the cost of ignoring it.
    To see what Oracle is thinking run an explain plan using DBMS_XPLAN for create the output and then rerun it with a hint forcing index usage.
    It is a mistake to believe that an index will always make things better. Issues of cardinality, clustering factor, etc. are very important.
    Post the explain plans if you have any questions about what they show:
    http://www.psoug.org/reference/explain_plan.html

  • Query is not using the cache

    We are on 7.3 and I have been doing some performance tuning.  I've noticed that even though a query is in the query aggregate in the cache monitor when I run it for the 1st time every morning it does not use the cache.  I traced it from ST05 and verified this.   However when I  run it the second time during the day it uses the cache.  The query cache mode is set to 5.  do you know why it does this?  I am using the exact same parameters when I run the query every time.

    You need to use following process of process chain: "Attribute change run (ATTRIBCHAN)". This process needs to be incorporated into your process chains which loads data into provider on top of which your query is based.
    See following links on topic how to build it:
    https://help.sap.com/saphelp_nw73/helpdata/en/4a/5da82c7df51cece10000000a42189b/frameset.htm
    https://help.sap.com/saphelp_nw70ehp1/helpdata/en/9a/33853bbc188f2be10000000a114084/content.htm
    cheers
    m./

  • Select is not using the Index

    Hi,
    I have a Z-Table. The Primary key is:
    EQUNR and LFDNR
    I created now a new index with the field: EQUNR BSTNK .
    Now I entered 3 equnrs and bstnk like 07* in SE16n
    Normally what I thought should happen is that it uses the index to read the three equipments and than checks the field bstnk.
    Instead it does a sequentiel read of the hole table that contains 12mio entries!
    When I enter the bstnk more qualified like 0712354* the search is fast (1sec). Why is SAP bypassing the index and does a sequentiel read instead?!

    Hi I checked,
    ST05 the fast run was using an Index, the second didn't!
    Thanks to  John. After I started a runstat on this table it worked.
    But  the weird thing is when I use a inner join between my Z-Table and the EQUI table it doesn't use the index.
    When I first select all equnrs in EQUI and then select the data from my z-Table with for all entries it uses my new index!
    Example:
    EQUNR has Index on field SERNR
    Z-Table has Index on EQUNR + BSTNK
    in sernrs I have ~5 full qualified sernos
    in bstnk I have something like 07*
    3 of these serialnumbers are in a bstnk that begins with 07.
              select *
                into corresponding fields of table search_result
                from equi as a
                inner join z-table as b on b~equnr = a~equnr
                where   a~sernr     in sernrs
                  and   b~bstnk     in bstnks
    After 5 min I have to kill the process. in SM50 I can see sequential read...
    When I do this:
            select equnr
              from equi
              into corresponding fields of table lt_search_result
              where sernr in sernrs.
              select *
                from z_table
                into corresponding fields of table lt_search_result
                for all entries in lt_search_result
                where equnr = lt_search_result-equnr
                  and bstnk in bstnks.
    It takes 2sec and I got the result.
    Edited by: Daniel Winter on Apr 21, 2010 8:51 AM
    Edited by: Daniel Winter on Apr 21, 2010 8:51 AM

  • Query on virtual column that is defined in XMLIndex does not use the index

    Hello,
    I am facing an issue in executing queries on a virtual column that is defined in an XMLIndex: it appears as if the index is not used.
    Database details:
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE 11.2.0.3.0 Production
    TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    For this use case the XML documents adhere to the following XSD and are stored in an XMLType column in a table:
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns="http://a_name_space/v1"
        targetNamespace="http://a_name_space/v1"
        elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">
        <xsd:element name="fields">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="field" maxOccurs="unbounded">
                        <xsd:complexType>
                            <xsd:choice>
                                <xsd:element name="value" minOccurs="1" maxOccurs="1">
                                    <xsd:complexType>
                                        <xsd:simpleContent>
                                            <xsd:extension base="notEmptyString4000Type"/>
                                        </xsd:simpleContent>
                                    </xsd:complexType>
                                </xsd:element>
                                <xsd:element name="values" minOccurs="1" maxOccurs="1">
                                    <xsd:complexType>
                                        <xsd:sequence>
                                            <xsd:element name="value" minOccurs="1" maxOccurs="1">
                                                <xsd:complexType>
                                                    <xsd:simpleContent>
                                                        <xsd:extension base="notEmptyString4000Type">
                                                            <xsd:attribute name="startDate" type="xsd:date" use="required"/>
                                                            <xsd:attribute name="endDate" type="xsd:date" />
                                                        </xsd:extension>
                                                    </xsd:simpleContent>
                                                </xsd:complexType>
                                            </xsd:element>
                                        </xsd:sequence>
                                    </xsd:complexType>
                                </xsd:element>
                            </xsd:choice>
                            <xsd:attribute name="name" type="string30Type" use="required"/>
                            <xsd:attribute name="type" type="dataType" use="required"/>
                        </xsd:complexType>
                    </xsd:element>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
        <xsd:simpleType name="dataType">
            <xsd:annotation>
                <xsd:documentation>Char, Date, Number</xsd:documentation>
            </xsd:annotation>
            <xsd:restriction base="xsd:string">
                <xsd:enumeration value="C"/>
                <xsd:enumeration value="D"/>
                <xsd:enumeration value="N"/>
            </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="string30Type">
            <xsd:restriction base="xsd:string">
                <xsd:maxLength value="30"/>
            </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="notEmptyString4000Type">
            <xsd:restriction base="xsd:string">
                <xsd:maxLength value="4000"/>
                <xsd:pattern value=".+"/>
            </xsd:restriction>
        </xsd:simpleType>
    </xsd:schema>A field can have a single value as well as multiple values.
    The XMLIndex is defined as follows:
    CREATE INDEX test_xmltype_idx ON test_xmltype (additional_fields) INDEXTYPE IS XDB.XMLIndex
    PARAMETERS
    XMLTable dt_fld_tab (TABLESPACE "TAB_SPACE" COMPRESS FOR OLTP) ''fields/field''
    COLUMNS
    name varchar2(30 char) PATH ''@name''
    ,dataType varchar2(1 char) PATH ''@type''
    ,val varchar2(4000 char) PATH ''value/text()''
    ,vals XMLType PATH ''values/value'' VIRTUAL
    XMLTable dt_fld_multi_value_tab (TABLESPACE "TAB_SPACE" COMPRESS FOR OLTP) ''value'' passing vals
    COLUMNS
    val varchar2(4000) PATH ''text()''
    ,startDate varchar2(30 char) PATH ''@startDate''
    ,endDate varchar2(30 char) PATH ''@endDate''
    ');The following b-tree indexes are defined:
    create index dt_field_name_idx on dt_fld_tab (name);
    create index dt_field_value_idx on dt_fld_tab (val);
    create index dt_field_values_idx on dt_fld_multi_value_tab (val);And stats are properly computed before the queries are executed:
    call dbms_stats.gather_table_stats(user, 'test_xmltype', estimate_percent => null);Queries for single values are cost efficient and fast. With 600K rows in the table these return with 0.002 seconds.
    Queries for multi-valued fields / elements are not though, these result in a full table scan.
    Sample XML snippet:
    <fields>
      <field name="multiVal" type="C">
        <values>
          <value startDate="2013-01-01" endDate="2013-01-01">100</value>
          <value startDate="2014-01-01">120</value>
        </values>
      </field>
    </fields>Examples of costly and slow queries:
    select id from test_xmltype
    where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
    and xmlexists('/fields/field/values/value[@startDate="2013-01-01"]' passing additional_fields)
    and xmlexists('/fields/field/values/value[text()="100"]' passing additional_fields)
    select id from test_xmltype
    where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
    and xmlexists('/fields/field/values/value[@startDate="2013-01-01" and .="100"]' passing additional_fields);Whereas the following query on the multi valued field is fast:
    select id from test_xmltype
    where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
    and xmlexists('/fields/field/values/value[@startDate="2013-01-01"]' passing additional_fields);For the XPath /fields/field/values/value[@startDate="2013-01-01"] the index is used.
    Suspected cause: XPath issue for the value of a multi valued field, e.g. /fields/field/values/value[text()="aValue"].
    Any hints are appreciated: what am I overlooking here?
    Thanks in advance,
    -Sjoerd
    Edited by: user615230 on May 27, 2013 7:46 AM

    Hello,
    This is using binary XML. The table creation script is:
    create table test_xmltype
    (id number(14,0) not null primary key
    ,member_code varchar2(30 char) not null
    ,period_code varchar2(30 char) not null
    ,amount number(12,2) not null
    ,additional_fields xmltype
    );The schema is not registered in the database. Is that required? It is primarily used to generate Java classes that will be used in order to construct the XML documents.
    And you are right: for our initial investigation the sample XML documents are generated with a PLSQL routine and do not contain namespaces. But for the single valued fields there are also no namespaces and the queries on these are executed with very satisfactory plans.
    Thanks for the swift reply.
    -Sjoerd

  • Query startdate and end date not using the index

    Hi,
    in my query all the where  i am using  the code as below
    AND START_DATE                   <= SYSDATE
    AND SYSDATE  <= END_DATE
    because of this my query seems to slow and timeconsuming. is there any other alternate way?
    Pls help
    S

    KARTHIK,
    this is my query
    SELECT /*+ PARALLEL(CUSTOMER, 4)PARALLEL(CUSTOMER_MANAGER, 4),PARALLEL(CUSTOMER_DIVISION, 4) */
    CUSTOMER.CUSTOMER_EID 
    FROM  CUSTOMER_   CUSTOMER,
    CUSTOMER_MANAGER_ CUSTOMER_MANAGER,
    CUSTOMER_DIVISION_   CUSTOMER_DIVISION
    WHERE   CUSTOMER_MANAGER.CUSTOMER_EID   = CUSTOMER.CUSTOMER_EID
    AND CUSTOMER.CUSTOMER_EID               = CUSTOMER_DIVISION.CUSTOMER_EID
    AND  CUSTOMER_MANAGER.CUSTOMER_EID   = CUSTOMER_DIVISION.CUSTOMER_EID
    AND ( TRUNC(SYSDATE) BETWEEN CUSTOMER_MANAGER.DIVISION_START_DATE   AND CUSTOMER_MANAGER.DIVISION_END_DATE
    AND  TRUNC(SYSDATE) BETWEEN CUSTOMER_DIVISION.DIVISION_START_DATE   AND CUSTOMER_DIVISION.DIVISION_END_DATE )
    AND CUSTOMER_DIVISION.STATUS             ='AC';
    plan output is as below
    Plan hash value: 2500183415
    | Id  | Operation                     | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT              |                   |     1 |    53 |       |   360K  (1)| 01:12:04 |       |       |        |      |            |
    |   1 |  PX COORDINATOR               |                   |       |       |       |            |          |       |       |        |      |            |
    |   2 |   PX SEND QC (RANDOM)         | :TQ10001          |     1 |    53 |       |   360K  (1)| 01:12:04 |       |       |  Q1,01 | P->S | QC (RAND)  |
    |   3 |    NESTED LOOPS               |                   |     1 |    53 |       |   360K  (1)| 01:12:04 |       |       |  Q1,01 | PCWP |            |
    |*  4 |     HASH JOIN                 |                   |    16M|   738M|   111M|   360K  (1)| 01:12:03 |       |       |  Q1,01 | PCWP |            |
    |   5 |      BUFFER SORT              |                   |       |       |       |            |          |       |       |  Q1,01 | PCWC |            |
    |   6 |       PX RECEIVE              |                   |    12M|   302M|       |   305K  (1)| 01:01:10 |       |       |  Q1,01 | PCWP |            |
    |   7 |        PX SEND PARTITION (KEY)| :TQ10000          |    12M|   302M|       |   305K  (1)| 01:01:10 |       |       |        | S->P | PART (KEY) |
    |   8 |         PARTITION HASH ALL    |                   |    12M|   302M|       |   305K  (1)| 01:01:10 |     1 |     4 |        |      |            |
    |*  9 |          TABLE ACCESS FULL    | CUSTOMER_DIVISION_ |    12M|   302M|       |   305K  (1)| 01:01:10 |     1 |     4 |        |      |            |
    |  10 |      PX PARTITION HASH ALL    |                   |    15M|   323M|       | 42663   (1)| 00:08:32 |     1 |     4 |  Q1,01 | PCWC |            |
    |* 11 |       TABLE ACCESS FULL       | CUSTOMER_MANAGER_ |    15M|   323M|       | 42663   (1)| 00:08:32 |     1 |     4 |  Q1,01 | PCWP |            |
    |* 12 |     INDEX UNIQUE SCAN         | CUSTOMER__PK      |     1 |     6 |       |     1   (0)| 00:00:01 |       |       |  Q1,01 | PCWP |            |
    Query Block Name / Object Alias (identified by operation id):
       1 - SEL$1
       9 - SEL$1 / CUSTOMER_DIVISION@SEL$1
      11 - SEL$1 / CUSTOMER_MANAGER@SEL$1
      12 - SEL$1 / CUSTOMER@SEL$1
    Predicate Information (identified by operation id):
       4 - access("CUSTOMER_MANAGER"."CUSTOMER_EID"="CUSTOMER_DIVISION"."CUSTOMER_EID")
       9 - filter("CUSTOMER_DIVISION"."STATUS"='AC' AND "CUSTOMER_DIVISION"."DIVISION_END_DATE">=TRUNC(SYSDATE@!) AND
                  "CUSTOMER_DIVISION"."DIVISION_START_DATE"<=TRUNC(SYSDATE@!))
      11 - filter("CUSTOMER_MANAGER"."DIVISION_END_DATE">=TRUNC(SYSDATE@!) AND "CUSTOMER_MANAGER"."DIVISION_START_DATE"<=TRUNC(SYSDATE@!))
      12 - access("CUSTOMER"."CUSTOMER_EID"="CUSTOMER_DIVISION"."CUSTOMER_EID")
           filter("CUSTOMER_MANAGER"."CUSTOMER_EID"="CUSTOMER"."CUSTOMER_EID")
    Column Projection Information (identified by operation id):
       1 - "CUSTOMER"."CUSTOMER_EID"[NUMBER,22]
       2 - (#keys=0) "CUSTOMER"."CUSTOMER_EID"[NUMBER,22]
       3 - (#keys=0) "CUSTOMER"."CUSTOMER_EID"[NUMBER,22]
       4 - (#keys=1) "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22], "CUSTOMER_MANAGER"."CUSTOMER_EID"[NUMBER,22]
       5 - (#keys=0) "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22]
       6 - "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22]
       7 - (#keys=1) "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22]
       8 - "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22]
       9 - "CUSTOMER_DIVISION"."CUSTOMER_EID"[NUMBER,22]
      10 - "CUSTOMER_MANAGER"."CUSTOMER_EID"[NUMBER,22]
      11 - "CUSTOMER_MANAGER"."CUSTOMER_EID"[NUMBER,22]
      12 - "CUSTOMER"."CUSTOMER_EID"[NUMBER,22]
    Pls suggest
    s

  • Not using the index

    hi all,
    DB version is 10.2.0.4
    Have a query as below
    SQL> explain plan for SELECT GS.LOT_NO , GS.LOT_ID , ILI.ITEM_ID ITEM_ID,
      2               GR.RESULT_VALUE_CHAR QUALITATIVE_VALUE , ITM.ITEM_NO FROM
                 GMD_QC_TESTS GQT, GMD_RESULTS GR, GMD_SAMPLES GS , IC_LOCT_INV
      3    4               ILI, IC_ITEM_MST_B ITM WHERE GQT.TEST_CODE = 'ISON' AND
      5               GR.TEST_ID = GQT.TEST_ID AND GR.RESULT_VALUE_CHAR LIKE :B3
      6               ||'-'||:B2 ||'%' AND GR.SAMPLE_ID = GS.SAMPLE_ID AND ITM.ITEM_ID
      7               = GS.ITEM_ID AND ILI.WHSE_CODE = UPPER(:B1 ) AND ILI.ITEM_ID =
      8               GS.ITEM_ID AND ILI.LOT_ID = GS.LOT_ID AND ILI.LOCT_ONHAND > 0
      9               AND ILI.LOT_ID > 0 AND ILI.LOT_STATUS = 'GOOD' AND NOT EXISTS (
    10               SELECT 1 FROM IC_TRAN_PND ITP WHERE ITP.LOT_ID = GS.LOT_ID AND
    11               ITP.ITEM_ID = GS.ITEM_ID AND ITP.DELETE_MARK = 0 AND
    12               ITP.DOC_TYPE = 'OMSO' AND ITP.WHSE_CODE = UPPER(:B1 ) AND LOT_ID
    13               <> 0 ) ORDER BY 4
    14  /
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2952119331
    | Id  | Operation                          | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                   |                    |    55 |  7095 | 13614   (1)| 00:02:51 |
    |   1 |  SORT ORDER BY                     |                    |    55 |  7095 | 13614   (1)| 00:02:51 |
    |   2 |   NESTED LOOPS ANTI                |                    |    55 |  7095 | 13613   (1)| 00:02:51 |
    |   3 |    NESTED LOOPS                    |                    |    55 |  5940 | 13393   (1)| 00:02:49 |
    |*  4 |     HASH JOIN                      |                    |    55 |  4730 | 13283   (1)| 00:02:47 |
    |*  5 |      TABLE ACCESS BY INDEX ROWID   | IC_LOCT_INV        | 17498 |   410K|  4056   (1)| 00:00:51 |
    |*  6 |       INDEX RANGE SCAN             | IC_LOCT_INV_I1     | 52570 |       |   137   (0)| 00:00:02 |
    |*  7 |      HASH JOIN                     |                    | 14944 |   904K|  9226   (1)| 00:01:56 |
    |   8 |       NESTED LOOPS                 |                    | 14944 |   452K|   212   (0)| 00:00:03 |
    |   9 |        NESTED LOOPS                |                    |     1 |    19 |     2   (0)| 00:00:01 |
    |  10 |         TABLE ACCESS BY INDEX ROWID| GMD_QC_TESTS_B     |     1 |    12 |     2   (0)| 00:00:01 |
    |* 11 |          INDEX UNIQUE SCAN         | GMD_QC_TESTS_B_U1  |     1 |       |     1   (0)| 00:00:01 |
    |* 12 |         INDEX UNIQUE SCAN          | GMD_QC_TESTS_TL_PK |   508 |  3556 |     0   (0)| 00:00:01 |
    |  13 |        TABLE ACCESS BY INDEX ROWID | GMD_RESULTS        | 14944 |   175K|   210   (0)| 00:00:03 |
    |* 14 |         INDEX RANGE SCAN           | GMD_RESULTS_N3     |   228 |       |     3   (0)| 00:00:01 |
    |* 15 |       TABLE ACCESS FULL            | GMD_SAMPLES        |  1642K|    48M|  9007   (1)| 00:01:54 |
    |  16 |     TABLE ACCESS BY INDEX ROWID    | IC_ITEM_MST_B      |     1 |    22 |     2   (0)| 00:00:01 |
    |* 17 |      INDEX UNIQUE SCAN             | IC_ITEM_MST_B_PK   |     1 |       |     1   (0)| 00:00:01 |
    |* 18 |    TABLE ACCESS BY INDEX ROWID     | IC_TRAN_PND        |     1 |    21 |     4   (0)| 00:00:01 |
    |* 19 |     INDEX RANGE SCAN               | IC_TRAN_PNDI1      |     1 |       |     3   (0)| 00:00:01 |
    ---------------------------------------------------------------------------------------------------------In that full table scan happening on GMD_SAMPLES. Lot_id is selected from that table. On that colum index exists in the table. But its not being used??
    SQL> select dbms_metadata.get_ddl('INDEX','GMD_SAMPLES_N3','GMD') from dual;
      CREATE INDEX "GMD"."GMD_SAMPLES_N3" ON "GMD"."GMD_SAMPLES" ("LOT_ID")
      PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
      STORAGE(INITIAL 131072 NEXT 131072 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "APPS_TS_TX_DATA"How do i bring down the cost of the query.?.This query runs for more than 2 hours in the db..
    thanks,
    baskar.l

    WHY MY INDEX IS NOT BEING USED
    http://communities.bmc.com/communities/docs/DOC-10031
    http://searchoracle.techtarget.com/tip/Why-isn-t-my-index-getting-used
    http://www.orafaq.com/tuningguide/not%20using%20index.html
    SELECT gs.lot_no,
           gs.lot_id,
           ili.item_id          item_id,
           gr.result_value_char qualitative_value,
           itm.item_no
    FROM   gmd_qc_tests gqt,
           gmd_results gr,
           gmd_samples gs,
           ic_loct_inv ili,
           ic_item_mst_b itm
    WHERE  gqt.test_code = 'ISON'
           AND gr.test_id = gqt.test_id
           AND gr.result_value_char LIKE :B3
                                         ||'-'
                                         ||:B2
                                         ||'%'
           AND gr.sample_id = gs.sample_id
           AND itm.item_id = gs.item_id
           AND ili.whse_code = Upper(:B1)
           AND ili.item_id = gs.item_id
           AND ili.lot_id = gs.lot_id
           AND ili.loct_onhand > 0
           AND ili.lot_id > 0
           AND ili.lot_status = 'GOOD'
           AND NOT EXISTS (SELECT 1
                           FROM   ic_tran_pnd itp
                           WHERE  itp.lot_id = gs.lot_id
                                  AND itp.item_id = gs.item_id
                                  AND itp.delete_mark = 0
                                  AND itp.doc_type = 'OMSO'
                                  AND itp.whse_code = Upper(:B1)
                                  AND lot_id = 0)
    ORDER  BY 4  Edited by: sb92075 on Aug 19, 2010 7:09 AM

  • SQL Query not using Composite Index

    Hi,
    Please look at the below query:
    SELECT pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    ,SUM(decode(pde.distribution_type
    ,'FORFEITURE'
    ,pde.forfeited_quantity *
    pde.sold_price * cc.rate
    ,pde.distributed_quantity *
    pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
    FROM part_distribution_exec pde
    ,currency_conversion cc
    ,currency off_curr
    WHERE pde.participant_uid = 4105
    AND off_curr.currency_iso_code =
    pde.offering_currency_iso_code
    AND cc.from_currency_uid = off_curr.currency_uid
    AND cc.to_currency_uid = 1
    AND cc.latest_flag = 'Y'
    GROUP BY pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
    I don't want this drop and recreation of index daily, I need a permanent solution for this.
    Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
    -Sankar

    Hi David,
    This is Sankar here. Thankyou for your reply.
    I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
    | 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
    |* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
    | 3 | SORT AGGREGATE | | 1 | 67 | |
    |* 4 | FILTER | | | | |
    |* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
    | 6 | SORT AGGREGATE | | 1 | 94 | |
    |* 7 | FILTER | | | | |
    |* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
    |* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
    |* 10 | FILTER | | | | |
    |* 11 | HASH JOIN | | 26 | 15678 | 95 |
    |* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
    |* 13 | HASH JOIN | | 26 | 10218 | 86 |
    | 14 | VIEW | | 1 | 82 | 4 |
    | 15 | SORT GROUP BY | | 1 | 116 | 4 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
    |* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
    |* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
    |* 19 | HASH JOIN | | 26 | 6006 | 71 |
    | 20 | NESTED LOOPS | | 36 | 5904 | 66 |
    | 21 | NESTED LOOPS | | 1 | 115 | 65 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
    |* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
    | 24 | VIEW | | 1 | 73 | 4 |
    | 25 | SORT GROUP BY | | 1 | 71 | 4 |
    | 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
    |* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
    |* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
    |* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
    | 31 | VIEW | | 1 | 80 | 10 |
    | 32 | SORT GROUP BY | | 1 | 198 | 10 |
    |* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
    | 34 | NESTED LOOPS | | 1 | 198 | 8 |
    | 35 | NESTED LOOPS | | 2 | 312 | 4 |
    | 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
    |* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
    | 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
    |* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
    |* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
    | 41 | VIEW | | 1 | 53 | 4 |
    | 42 | SORT GROUP BY | | 1 | 62 | 4 |
    |* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
    |* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
    | 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
    |* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
    Predicate Information (identified by operation id):
    2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
    "PAPS"."INSTALLMENT_NUM"=1)
    4 - filter(4105=:B1)
    5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    7 - filter(4105=:B1)
    8 - filter("PAPS"."STATUS"='OPEN')
    9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
    "EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
    11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
    12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
    13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
    16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
    17 - access("PAL1"."PARTICIPANT_UID"=4105)
    filter("PAL1"."PARTICIPANT_UID"=4105)
    18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
    19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
    23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
    27 - access("PAV"."PARTICIPANT_UID"=4105)
    filter("PAV"."PARTICIPANT_UID"=4105)
    29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
    "SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
    30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
    33 - filter("CC"."LATEST_FLAG"='Y')
    37 - access("PDE"."PARTICIPANT_UID"=4105)
    filter("PDE"."PARTICIPANT_UID"=4105)
    39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
    40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
    43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
    44 - access("PV"."PARTICIPANT_UID"=4105)
    filter("PV"."PARTICIPANT_UID"=4105)
    47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
    Note: cpu costing is off
    93 rows selected.
    Please help me out...
    -Sankar

  • Index not using the base table

    Hi,
    In which scenario, a query will only use the index and not the base table. Please give me some example.
    Thanks,
    Santhosh
    Edited by: Santhosh on Oct 23, 2012 2:45 AM

    Chancal,
    not always,
    SQL> desc temp;
    Name                                                                                                      Null?    Type
    EMPNO                                                                                                              NUMBER(4)
    ENAME                                                                                                              VARCHAR2(10)
    JOB                                                                                                                VARCHAR2(9)
    MGR                                                                                                                NUMBER(4)
    HIREDATE                                                                                                           DATE
    SAL                                                                                                                NUMBER(7,2)
    COMM                                                                                                               NUMBER(7,2)
    DEPTNO                                                                                                             NUMBER(2)
    SQL> select empno from temp;
         EMPNO
          7369
          7499
          7521
          7566
          7654
          7698
          7782
          7788
          7839
          7844
          7876
          7900
          7902
          7934
          1057
    15 rows selected.
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    SQL_ID  3qt0w20pqj162, child number 0
    select empno from temp
    Plan hash value: 3800668828
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |       |       |     2 (100)|          |
    |   1 |  TABLE ACCESS FULL| TEMP |    15 |    60 |     2   (0)| 00:00:01 |
    13 rows selected.
    SQL> alter table temp modify(empno not null);
    Table altered.
    SQL> select empno from temp;
         EMPNO
          1057
          7369
          7499
          7521
          7566
          7654
          7698
          7782
          7788
          7839
          7844
          7876
          7900
          7902
          7934
    15 rows selected.
    SQL> select * from table(dbms_xplan.display_cursor);
    PLAN_TABLE_OUTPUT
    SQL_ID  3qt0w20pqj162, child number 0
    select empno from temp
    Plan hash value: 472861760
    | Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT |          |       |       |     1 (100)|          |
    |   1 |  INDEX FULL SCAN | IDX_TEMP |    15 |    60 |     1   (0)| 00:00:01 |
    13 rows selected.

  • Qeury not using the bitmap index

    Hi,
    Pls have a look at the query below:
    SELECT
    A.flnumber,
    A.fldate,
    SUBSTR(C.sec,1,3) sect,
    D.element,
    C.class,
    SUM(C.qty) qty,
    A.indicator,
    DECODE(A.indicator, 'I', B.inrt, 'O', B.outrt, 'R', B.rting, NULL) direction,
    B.rting
    FROM
    Header A,
    Paths B,
    PathData C,
    ElementData D
    WHERE
    (D.category='N') AND
    (A.rt=B.rt) AND
    (C.element=D.element) AND
    (A.fldate=C.fldate AND
    A.flnumber=C.flnumber) AND
    C.element IN (SELECT codes FROM Master_codes WHERE type='F')
    GROUP BY A.flnumber,
         A.fldate,
         SUBSTR(C.sec, 1, 3),
         D.element,
         C.class,
         A.indicator,
         DECODE(A.indicator,'I', B.inrt, 'O', B.outrt,'R', B.rting, NULL),
    B.rting
    UNION ALL
    SELECT
    A.flnumber,
    A.fldate,
    SUBSTR(C.sec,1,3) sect,
    D.element,
    C.class,
    SUM(C.qty) qty,
    A.indicator,
    DECODE(A.indicator, 'I', B.inrt, 'O', B.outrt, 'R', B.rting, NULL) ROUTE_direction,
    B.rting
    FROM
    Header A,
    Paths B,
    PathData C,
    ElementData D
    WHERE
    (D.category='N') AND
    (A.rt=B.rt) AND
    (C.element=D.element) AND
    (A.fldate=C.fldate AND
    A.flnumber=C.flnumber) AND
    C.element NOT IN (SELECT codes FROM Master_codes WHERE type='F')
    GROUP BY A.flnumber,
         A.fldate,
         SUBSTR(C.sec, 1, 3),
         D.element,
         C.class,
         A.indicator,
         DECODE(A.indicator,'I', B.inrt, 'O', B.outrt,'R', B.rting, NULL),
    B.rting
    The cost in the explain plan is very high. The table PathData* has 42710366 records and there is a bitmap index on the flnumber_ and fldate* columns. But the query above does not use the indexes. The other tables in the list are fine as their respective PK and indexes are used but the table PathData* is going for a "Table Access by Local Index Rowid". dont know what it means but the cost for this is 7126 which is high. I cant figure out why is the query not using the bitmap indexes for this table.
    Pls let me know what should be done.???

    Thread: HOW TO: Post a SQL statement tuning request - template posting
    HOW TO: Post a SQL statement tuning request - template posting
    SELECT a.flnumber,
           a.fldate,
           Substr(c.sec, 1, 3)       sect,
           d.element,
           c.class,
           SUM(c.qty)                qty,
           a.INDICATOR,
           Decode(a.INDICATOR, 'I', b.inrt,
                               'O', b.outrt,
                               'R', b.rting,
                               NULL) direction,
           b.rting
    FROM   header a,
           paths b,
           pathdata c,
           elementdata d
    WHERE  ( d.category = 'N' )
           AND ( a.rt = b.rt )
           AND ( c.element = d.element )
           AND ( a.fldate = c.fldate
                 AND a.flnumber = c.flnumber )
           AND c.element IN (SELECT codes
                             FROM   master_codes
                             WHERE  TYPE = 'F')
    GROUP  BY a.flnumber,
              a.fldate,
              Substr(c.sec, 1, 3),
              d.element,
              c.class,
              a.INDICATOR,
              Decode(a.INDICATOR, 'I', b.inrt,
                                  'O', b.outrt,
                                  'R', b.rting,
                                  NULL),
              b.rting
    UNION ALL
    SELECT a.flnumber,
           a.fldate,
           Substr(c.sec, 1, 3)       sect,
           d.element,
           c.class,
           SUM(c.qty)                qty,
           a.INDICATOR,
           Decode(a.INDICATOR, 'I', b.inrt,
                               'O', b.outrt,
                               'R', b.rting,
                               NULL) route_direction,
           b.rting
    FROM   header a,
           paths b,
           pathdata c,
           elementdata d
    WHERE  ( d.category = 'N' )
           AND ( a.rt = b.rt )
           AND ( c.element = d.element )
           AND ( a.fldate = c.fldate
                 AND a.flnumber = c.flnumber )
           AND c.element NOT IN (SELECT codes
                                 FROM   master_codes
                                 WHERE  TYPE = 'F')
    GROUP  BY a.flnumber,
              a.fldate,
              Substr(c.sec, 1, 3),
              d.element,
              c.class,
              a.INDICATOR,
              Decode(a.INDICATOR, 'I', b.inrt,
                                  'O', b.outrt,
                                  'R', b.rting,
                                  NULL),
              b.rting  Edited by: sb92075 on Mar 13, 2011 7:58 AM

Maybe you are looking for

  • HP LaserJet CP1518 only printing black and white!

    Here is a weird issue. Today, my HP color LaserJet will only print Pages documents in B&W! The document in question printed in color yesterday. I tried a new document, and that one printed B&W! I 'printed' to a PDF and in Preview it was color, but pr

  • ITunes froze while updating iPod firmware...

    I was trying to install the latest version of software on my iPod touch (4gen) and it's frozen halfway through. My iPod has a little loading bar on it, as does iTunes, both are maybe a third of the way through and have been stuck on the exact same sp

  • Interview questions.......help me

    what is the main difference between move and move-corresponding? what is default join when ur using join for two internal tables? what is field group?where we can use this? what is data analasys concept? what is client concept? give me some best site

  • Internals of Packager for iPhone

    Hello, just out of curiosity. Does anyone of you know what exactly does the "Packager for iPhone" does? At first, I thought that it was some kind of cross-compiler from swf bytecode to Obj-C/arm code; because of Apple Restrictions, and because of the

  • Duplicate BPM

    Hi, I install BPM standalone 10.3.1 and oracle 10.2.0.2 in a machine about half years ago. There are hundreds of process instances in the workspace. This week I install BPM standalone 10.3.1 and oracle 10g in another machine. I import the organizatio