Query with using single index

I have what seems like a pretty straight forward problem. I have a table, say TAB_A that has a NAME, PHONE, SSN along with some other values (no primary key...I know, don't start with me. That's just the way it is.) I want to retrieve records where the NAME or the PHONE, or the SSN match a static value. I realize I could write this as:
WHERE name = 'Joe' OR phone = '5556667777' or ssn = '012345678'
However, when you do this (assuming there is a concatenated index on name, phone, ssn), you end up doing an index full scan. If you create three individual indexes on each column then you can write a union query that utilizes the index for each value...eg.
select...
where name = 'Joe'
union
select...
where phone = '555667777'
union
etc.
However, here you are writing three separate queries that each do an index range scan. I'm just wondering if there is some way to do this...say with some sort of function based index and a hashing algorithm applied to the data where I can do this in a single index range scan? Any ideas?

I don't see how a single index entry can point to a row that doesn't exist (in all likelihood).
Without testing it, I don't see how even a concatenated index could help.
The rows returned by your query are completely unrelated (unless you find the one person who has all three).
By the way, 7 posts in 10 years. Now that's what I call a lurker.

Similar Messages

  • Can I refactor this query to use an index more efficiently?

    I have a members table with fields such as id, last name, first name, address, join date, etc.
    I have a unique index defined on (last_name, join_date, id).
    This query will use the index for a range scan, no sort required since the index will be in order for that range ('Smith'):
    SELECT members.*
            FROM members
            WHERE last_name = 'Smith'
            ORDER BY joindate, idIs there any way I can get something like the following to use the index (with no sort) as well:
    SELECT members.*
            FROM members
            WHERE last_name like 'S%'
            ORDER BY joindate, idI understand the difficulty is probably; even if it does a range scan on every last name 'S%' (assuming it can?), they're not necessarily in order. Case in point:
    Last_Name:  JoinDate:
    Smith          2/5/2010
    Smuckers     1/10/2010An index range scan of 'S%' would return them in the above order, which is not ordered by joindate.
    So is there any way I can refactor this (query or index) such that the index can be range scanned (using LIKE 'x%') and return rows in the correct order without performing a sort? Or is that simply not possible?

    xaeryan wrote:
    I have a members table with fields such as id, last name, first name, address, join date, etc.
    I have a unique index defined on (last_name, join_date, id).
    This query will use the index for a range scan, no sort required since the index will be in order for that range ('Smith'):
    SELECT members.*
    FROM members
    WHERE last_name = 'Smith'
    ORDER BY joindate, idIs there any way I can get something like the following to use the index (with no sort) as well:
    SELECT members.*
    FROM members
    WHERE last_name like 'S%'
    ORDER BY joindate, idI understand the difficulty is probably; even if it does a range scan on every last name 'S%' (assuming it can?), they're not necessarily in order. Case in point:
    Last_Name:  JoinDate:
    Smith          2/5/2010
    Smuckers     1/10/2010An index range scan of 'S%' would return them in the above order, which is not ordered by joindate.
    So is there any way I can refactor this (query or index) such that the index can be range scanned (using LIKE 'x%') and return rows in the correct order without performing a sort? Or is that simply not possible?Come on. Index column order does matter. "LIKE 'x%'" actually is full table scan. The db engine accesses contiguous index entries and then uses the ROWID values in the index to retrieve the table rows.

  • How can i know if my query is using the index ?

    Hello...
    How can i know if my query is using the index of the table or not?
    im using set autotrace on...but is there another way to do it?
    thanks!
    Alessandro Falanque.

    Hi,
    You can use Explain Plan for checking that your query is using proper index or not. First you need to check that Plan_table is installed in your database or not. If it is not there THEN THE SCRIPT WILL BE LIKE THIS:
    CREATE TABLE PLAN_TABLE (
    STATEMENT_ID VARCHAR2 (30),
    TIMESTAMP DATE,
    REMARKS VARCHAR2 (80),
    OPERATION VARCHAR2 (30),
    OPTIONS VARCHAR2 (30),
    OBJECT_NODE VARCHAR2 (128),
    OBJECT_OWNER VARCHAR2 (30),
    OBJECT_NAME VARCHAR2 (30),
    OBJECT_INSTANCE NUMBER,
    OBJECT_TYPE VARCHAR2 (30),
    OPTIMIZER VARCHAR2 (255),
    SEARCH_COLUMNS NUMBER,
    ID NUMBER,
    PARENT_ID NUMBER,
    POSITION NUMBER,
    COST NUMBER,
    CARDINALITY NUMBER,
    BYTES NUMBER,
    OTHER_TAG VARCHAR2 (255),
    PARTITION_START VARCHAR2 (255),
    PARTITION_STOP VARCHAR2 (255),
    PARTITION_ID NUMBER,
    OTHER LONG,
    DISTRIBUTION VARCHAR2 (30))
    TABLESPACE SYSTEM NOLOGGING
    PCTFREE 10
    PCTUSED 40
    INITRANS 1
    MAXTRANS 255
    STORAGE (
    INITIAL 10240
    NEXT 10240
    PCTINCREASE 50
    MINEXTENTS 1
    MAXEXTENTS 121
    FREELISTS 1 FREELIST GROUPS 1 )
    NOCACHE;
    After that write the following command in the SQL prompt.
    Explain plan for (Select statement);
    Select level, SubStr( lpad(' ',2*(Level-1)) || operation || ' ' ||
    object_name || ' ' || options || ' ' ||
    decode(id, null , ' ', decode(position, null,' ', 'Cost = ' || position) ),1,100)
    || ' ' || nvl(other_tag, ' ') Operation
    from PLAN_TABLE
    start with id = 0
    connect by
    prior id = parent_id;
    This will show how the query is getting executed . What are all the indexes it is using etc.
    Cheers.
    Samujjwal Basu

  • 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

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

  • Linking Access tables, creating a query with using both Access and Oracle

    Hello,
    I am using 3.0.04.34 version Oracle Developer. I am supposed to create a script/procedure to use both Access tables and oracle tables together. There is an option in developer to copy the access tables into oracle. But it doesn't help me. Because when we updated the access tables
    the copied ones are not be updated. How can I created a linked access tables to oracle and create a query with using both access and oracle table together.
    I will appreciate if you guys help me. I look forward to hearing from you guys.
    Thanks,
    Pinar

    Pinar,
    to be able to query MS Access tables in Oracle you need an additional product, the Oracle Database Gateway for ODBC. It allows you to link any foreign database into an Oracle database using a suitable ODBC driver. You can then access the MS Access tables through a database link based on the Database Gateway for ODBC. This will also allow you to join local Oracle and remote MS Access tables from your Oracle database.
    There's a note on My Oracle Support which gives you more details:Document 233876.1 Options for Connecting to Foreign Data Stores and Non-Oracle Databases - For example - DB2, SQL*Server, Sybase, Informix, Teradata, MySQL
    And there's also a dedicated Forum: Heterogeneous Connectivity

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

  • Spatial Query not using Spatial Index

    Hi All,
    I have a query which uses the SDO_WITHIN_DISTANCE operator, but is taking far too long to complete.
    SELECT
                   RT.*,RD.RPD_NODE_ID, RD.RPD_XCOORD,RD.RPD_YCOORD
              FROM
                   railplan_data RD
                   LEFT JOIN Walk_data_sets WDS ON RD.RPD_RPS_ID = WDS.WDS_RPS_ID
                   LEFT JOIN RWNet_Temp RT ON WDS.WDS_ID = RT.RW_WDS_ID
              WHERE
                   WDS.wds_id = 441
              AND
                   MDSYS.SDO_WITHIN_DISTANCE(RT.RW_GEOM,RD.RPD_GEOLOC,'DISTANCE=' || TO_CHAR(RT.RW_BUFFER) || ' UNIT=METER') = 'TRUE';
    Upon generation of the explain plan I have realised that the spatial index is not being used in the query, but I can't for the life of me get the thing working
    3     | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
    4     ------------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 25841 | 99M| | 201 |
    6     |* 1 | FILTER | | | | | |
    7     | 2 | MERGE JOIN OUTER | | | | | |
    8     |* 3 | HASH JOIN | | 12652 | 420K| 2968K| 185 |
    9     | 4 | TABLE ACCESS FULL | RAILPLAN_DATA | 75910 | 2075K| | 60 |
    10     | 5 | TABLE ACCESS BY INDEX ROWID| WALK_DATA_SETS | 1 | 6 | | 1 |
    11     |* 6 | INDEX UNIQUE SCAN | WDS_PK | 1 | | | |
    12     |* 7 | SORT JOIN | | 16 | 63760 | | 16 |
    13     |* 8 | TABLE ACCESS FULL | RWNET_TEMP | 16 | 63760 | | 4 |
    If anyone could help me out in figuring out why the spatial index is not being used, I would be most appreciative.
    TIA
    Dan

    Hi all again,
    Well I finally got an upgrade to Oracle 10 (yay!), so I am now trying to implement the SDO_JOIN method as per my earlier posts. In fact it is actually working, but I have a question. When I run an explain plan it does not show the use of any domain indexes which I would expect to see, but performs fine (1.07s) with just a few records (10 in 1 table, 15000 in the other), please see code and explain plan below:
    SELECT
      Distinct
        RT.RW_ID, RD.RPD_NODE_ID,
        RD.RPD_XCOORD,RD.RPD_YCOORD
    FROM
        RPD_TEMP_762 RD,
        WALK_DATA_SETS WDS,
        RWNET_TEMP RT,
        TABLE
        (SDO_JOIN
            (  'RWNET_TEMP',
                'RW_GEOM',
                'RPD_TEMP_762',
                'RPD_GEOLOC',
                'distance= ' || TO_CHAR(RT.RW_BUFFER) || ' unit=meter')) SPATIAL_JOIN_RESULT
    WHERE WDS.WDS_ID = RT.RW_WDS_ID
    AND WDS.WDS_ID = 762
    AND SPATIAL_JOIN_RESULT.ROWID1 = RT.ROWID
    AND SPATIAL_JOIN_RESULT.ROWID2 = RD.ROWID
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                           
    | Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)|                                                                                                                                                                                                                  
    |   0 | SELECT STATEMENT                     |              |    74 |  5994 | 21753   (1)|                                                                                                                                                                                                                  
    |   1 |  SORT UNIQUE                         |              |    74 |  5994 | 21691   (1)|                                                                                                                                                                                                                  
    |*  2 |   HASH JOIN                          |              |  1046K|    80M|  1859   (1)|                                                                                                                                                                                                                  
    |   3 |    NESTED LOOPS                      |              |  6076 |   213K|  1824   (1)|                                                                                                                                                                                                                  
    |   4 |     NESTED LOOPS                     |              |    74 |  2516 |   194   (1)|                                                                                                                                                                                                                  
    |*  5 |      INDEX UNIQUE SCAN               | WDS_PK       |     1 |     4 |     0   (0)|                                                                                                                                                                                                                  
    |*  6 |      TABLE ACCESS FULL               | RWNET_TEMP   |    74 |  2220 |   194   (1)|                                                                                                                                                                                                                  
    |*  7 |     COLLECTION ITERATOR PICKLER FETCH| SDO_JOIN     |       |       |            |                                                                                                                                                                                                                  
    |   8 |    TABLE ACCESS FULL                 | RPD_TEMP_762 | 17221 |   756K|    28   (0)|                                                                                                                                                                                                                  
    ------------------------------------------------------------------------------------------  When i try to add hints to force the use of spatial indexes the performance of this query drops through the floor (it takes minutes / hours), index hint shown below:
    /*+ ORDERED INDEX(RW rw_geom) INDEX(RD rpd_geoloc) */My question is is the first query using domain indexes, and if not, how do I get it to?
    TIA
    Dan

  • Why is this query not using my index ?

    hey
    i have the following situation
    (i'm sorry but i can't add the acctual script or output)
    create table x as
    select      level high_card ,
         mod(level,1000) medium_card ,
         mod(level,10) low_card ,
         '***' padding
    from     dual
    connect by level < 100001;
    create index x_med_low_ix on x(low_card,medium_card);
    create index x_high_ix on x(high_card);
    exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns size auto');
    i'm running the following query
    select      *
    from      x
    where      low_card = 70
    and     medium_card = 70
    and     high_card = 70;
    i'm expecting a range scan on the x_high_ix index. the optimizer expects only one row. the stats on the high_card columns shows that (num_rows * density = 1).
    when i run the query the optimizer uses the x_med_low_ix and does 14 cr.
    when i force the use of x_high_ix the cr goes down to 4.
    i don't want to declare x_high_ix as unique.
    so, why isn't he using my index ?

    It's using that index for me:
    SQL> create table x as
      2  select level high_card ,
      3  mod(level,1000) medium_card ,
      4  mod(level,10) low_card ,
      5  '***' padding
      6  from dual
      7  connect by level < 100001;
    Table created.
    SQL>
    SQL> create index x_med_low_ix on x(low_card,medium_card);
    Index created.
    SQL>
    SQL> create index x_high_ix on x(high_card);
    Index created.
    SQL>
    SQL> exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns
    size auto');
    PL/SQL procedure successfully completed.
    SQL> ed
    Wrote file afiedt.buf
      1   select *
      2   from x
      3   where low_card = 70
      4   and medium_card = 70
      5*  and high_card = 70
    SQL>
    SQL> /
    no rows selected
    Execution Plan
    Plan hash value: 775193209
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |           |     1 |    15 |     2   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS BY INDEX ROWID| X         |     1 |    15 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | X_HIGH_IX |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("LOW_CARD"=70 AND "MEDIUM_CARD"=70)
       2 - access("HIGH_CARD"=70)
    Statistics
              0  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            454  bytes sent via SQL*Net to client
            370  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> set autot off
    SQL> select * from v$version;
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Productionwhat is your version?
    By the way, when i force optimizer to use index X_MED_LOW_IX, it does 2 CR for me.

  • Why my query not using any index but doing a FULL TABLE SCAN

    Hi,
    My EXPLAIN PLAN output is
    Plan hash value: 1163866984                                                                                                                                                                                                                                                                                 
    | Id  | Operation               | Name              | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                                                                                                                                                                                       
    |   0 | SELECT STATEMENT        |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  1 |  FILTER                 |                   |       |       |       |            |          |                                                                                                                                                                                                       
    |   2 |   SORT GROUP BY         |                   |   774 |   159K|       | 40847   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  3 |    HASH JOIN            |                   | 77337 |    15M|  9744K| 40843   (2)| 00:08:11 |                                                                                                                                                                                                       
    |*  4 |     HASH JOIN           |                   | 77337 |  8836K|  5896K| 20987   (2)| 00:04:12 |                                                                                                                                                                                                       
    |*  5 |      HASH JOIN          |                   | 77337 |  4984K|       |  9292   (3)| 00:01:52 |                                                                                                                                                                                                       
    |*  6 |       HASH JOIN         |                   | 24991 |   951K|       |  3349   (3)| 00:00:41 |                                                                                                                                                                                                       
    |*  7 |        TABLE ACCESS FULL| IDS_TXNIDNUMBERS  | 24991 |   683K|       |  2328   (3)| 00:00:28 |                                                                                                                                                                                                       
    |   8 |        TABLE ACCESS FULL| IDS_TXNDEMDATAMAP |  2419K|    25M|       |  1006   (3)| 00:00:13 |                                                                                                                                                                                                       
    |   9 |       TABLE ACCESS FULL | IDS_IDNUMBERS     |  7435K|   191M|       |  5903   (2)| 00:01:11 |                                                                                                                                                                                                       
    |  10 |      TABLE ACCESS FULL  | IDS_DEMDATA       |  2583K|   125M|       |  3683   (5)| 00:00:45 |                                                                                                                                                                                                       
    |  11 |     TABLE ACCESS FULL   | IDS_TXN           |  2583K|   231M|       |  6403   (1)| 00:01:17 |                                                                                                                                                                                                       
    -----------------------------------------------------------------------------------------------------  All my 5 tables IDS_TXNIDNUMBERS, IDS_TXNDEMDATAMAP, IDS_IDNUMBERS,IDS_DEMDATA, IDS_TXN has indexes in relevant columns. Is it cause less time so CBO is not using the indexes.
    Thanks
    Amitava.

    amitavachatterjee1975 wrote:
    Please be polite when responding to my queries. If you find these questions not to your standard, stay away from them. This is an open forum and I have got my full rights to ask questions.Unsure, what wrong did you find in SB's reply. I find those links perfectly knowledgeable. The question of having so many unanswered questions probably pricked you a little too much. But that, IMO, is a legitimate question, to be asked to a User who even after being associated with OTN for over an year has 100% record of not getting an answer.
    For your original question, you will have to provide more details to allow people to answer you.
    You must read {message:id=3292438} and post the mentioned details. People do not carry a Crystal Ball to identify the problem merely by reading few lines of Problem description and Explain plans. Do not make people guess, provide appropriate details, to help them Help "You".

  • Query with Apostrophe (single quote)

    Hi all,
    I have noticed that when you enter a search string with an apostrophe (eg. Tito's Station) in a textbox on a form linked to a table and hit the Query button, it generates an sql error. I think this is cos u cannot have an apostrophe (single quote) in the search string in a "where" clause.
    I am using Portal version 3.0.6.6.5 on an 8.1.7 database.
    I have logged a tar (1744105.999) for this but it is said to be a bug (1759202). I wish to enquire whether any of you have had this problem with a later version or at which version leve this bug has been fixed.
    Does any1 know how to limit the text typed into a texbox, so that it wont accept certain characters (eg. the apostrophe key) ??
    Thanks

    Hi Rene'
    Thanks for your help! This will definitely help me alot! I am a little baffled with your code for delimiting the single quote. I tried it and it doesnt work.
    Thanks very much for the response
    Naseem
    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rene' Castle ([email protected]):
    This is still an issue in 3.0.8.9.8. You can use a Javascript validation routine to disallow special characters.
    If you want to check to see that they only enter certain things you can do:
    var s = theElement.value;
    var filter=/^[a-zA-Z]{1,}$/;
    if (s.length == 0 ) return true;
    if (filter.test(s))
    return true;
    else
    alert(" Please input a valid character" );
    theElement.focus();
    theElement.select();
    return false;
    The above code would only allow one or more alphabetic characters. You could make it [a-zA-Z0-9] to allow alphanumeric characters. You could also allow anything but specific characters by doing the following:
    var s = theElement.value;
    var filter=/[^']*/;
    if (s.length == 0 ) return true;
    if (filter.test(s))
    alert(" Please input a string without a single quote (') in it" );
    theElement.focus();
    theElement.select();
    return false;
    else
    return true;
    Hope this gets you started.
    Rene'<HR></BLOCKQUOTE>
    null

  • Issues with using XMLType indexes against a table with XMLType column

    I am attempting to use an XMLIndex with a Structured Component and not having too much luck. Not much data in metalink nor is the documentation very helpful:
    http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10492/xdb_indexing.htm#BCGHGIGC
    The table DDL is as follows:
    CREATE TABLE ECI_SCHEMA.REV_ITEM_EARN_DTL_VIRTUAL(
    REV_ITEM_EARN_DTL_ID_NBR NUMBER(16,0) NOT NULL,
    UNIQ_MSG_ID_NBR VARCHAR2(50) NOT NULL,
    REV_ITEM_BILL_DTL_ID_NBR NUMBER(16,0),
    PLAN_RACN_NBR NUMBER(10,0) NOT NULL,
    INV_DTL_IMG SYS.XMLType NOT NULL,
    NON_INV_DTL_IMG BLOB NOT NULL,
    PART_KEY_CD GENERATED ALWAYS AS (MOD(PLAN_RACN_NBR,5)) VIRTUAL,
    LAST_UPDT_TMSTP TIMESTAMP(6) NOT NULL,
    INV_ID_NBR NUMBER(16,0),
    ITEM_STATUS_CD VARCHAR2(1) DEFAULT 'A' NOT NULL
    LOB (NON_INV_DTL_IMG) STORE AS NON_IDI_LOB (CHUNK 8192 PCTVERSION 10 CACHE)
    TABLESPACE ECI_DATA
    PARTITION BY RANGE (PART_KEY_CD)
    PARTITION RIED_DAY0_PART
    VALUES LESS THAN (1)
    TABLESPACE ECI_DATA
    PARTITION RIED_DAY1_PART
    VALUES LESS THAN (2)
    TABLESPACE ECI_DATA
    PARTITION RIED_DAY2_PART
    VALUES LESS THAN (3)
    TABLESPACE ECI_DATA
    PARTITION RIED_DAY3_PART
    VALUES LESS THAN (4)
    TABLESPACE ECI_DATA
    PARTITION RIED_MAXVAL_PART
    VALUES LESS THAN (MAXVALUE)
    TABLESPACE ECI_DATA
    XMLTYPE COLUMN "INV_DTL_IMG" STORE AS OBJECT RELATIONAL
    XMLSCHEMA "someXdbDocument.xsd"
    ELEMENT "revenueInvoice"
    According to the documentation, I should be able to create a structured XMLIndex on the XMLType column with the following syntax:
    SQL> create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
    2 (INV_DTL_IMG)
    3 INDEXTYPE IS XDB.XMLIndex
    4 parameters ('PATH TABLE RIED_PATH_TABLE')
    5 local;
    When I do this, I get the following error:
    create index eci_schema.rev_item_earn_dtl_virt_xmlix on eci_schema.rev_item_earn_dtl_virtual
    ERROR at line 1:
    ORA-29958: fatal error occurred in the execution of ODCIINDEXCREATE routine
    ORA-30959: The indexed column is not stored in CLOB.
    What am I doing wrong? Based on the Oracle documentation, I was under the impression that 11.2 XMLIndex would work with Object Relational storage. Is this not the case?

    CREATE INDEX ECI_SCHEMA.REV_ITEM_EARN_DTL_IX7
           ON ECI_SCHEMA.REV_ITEM_EARN_DTL
                      extractValue(inv_dtl_img, '/revenueInvoice/service/transportation/mstrTrkngNbr')
    TABLESPACE ECI_REV_ITEM_EARN_DTL_IX7_ITS
    LOGGING
    PARALLEL(DEGREE 8 INSTANCES 1)
    LOCAL
    /Elements that occur at most once in each document can be indexed using extractValue(). Despite the fact that the index appears to be a functional index, when we create the index we automatically re-write the create index into a normal btree index on the column that contains the value for the element identified by the xpath.
    Eg in the case of a functional index based on extractValue, defined on XMLType using Object relational storage, with an xpath that identifies a node that occurs at most once in each document is not a functional index, it's re-written into a plain old vanilla btree index. You can actually check this by looking in the system tables
    Eg
    SQL> connect system/oracle
    Connected.
    SQL> select table_name, index_name from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
    TABLE_NAME                     INDEX_NAME
    PURCHASEORDER                  LINEITEM_TABLE_MEMBERS
    PURCHASEORDER                  ACTION_TABLE_MEMBERS
    PURCHASEORDER                  SYS_C0011037
    SQL> alter session set current_schema = OE
      2  /
    Session altered.
    SQL> create unique index PO_REF_INDEX on PURCHASEORDER (extractValue(object_value,'/PurchaseOrder/Reference'));
    Index created.
    SQL> set lines 250
    SQL> select index_name, index_type from all_indexes where owner = 'OE' and table_name = 'PURCHASEORDER';
    INDEX_NAME                     INDEX_TYPE
    PO_REF_INDEX                   NORMAL
    LINEITEM_TABLE_MEMBERS         NORMAL
    ACTION_TABLE_MEMBERS           NORMAL
    SYS_C0011037                   NORMAL
    SQL> select * from dba_ind_expressions where table_name = 'PURCHASEORDER' and index_owner = 'OE'
      2  /
    no rows selectedFrom the above we can see that the index created on extractValue has been re-written in a plain old vanilla BTREE index, and there is no definition for it in dba_ind_expressions So assuming you were able to create the index and insert the data you should find that your index is not a functional index.
    ]

  • "Improving SQL query performance using secondary indexes"

    I have a very old copy of this document from 1997. I'm hoping to find newer version, if one exists, but the search facility on SDN is not working at the moment. Does anyone have a more up to date copy or link they can point me to ?
    thanks,
    Malcolm.

    HI,
    check it out , may be it will help you
    [http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10743/schema.htm]
    [http://teradata.uark.edu/research/wang/indexes.html]
    [http://www.geekinterview.com/question_details/33720]

  • Use of index based on an attribute when doing an order by

    Hi,
    I create a table and its indexes like this:
    create table poc_wip2 of xmltype
    xmlschema "http://www.derwent.co.uk/wpi.xsd" element "WPI"
    alter table poc_wip2
    add constraint poc_wip2_pk primary key
    (XMLDATA."BibPt"."PDOC_COUNTRY",
    XMLDATA."BibPt".pdoc_serial, XMLDATA."BibPt".pdoc_kind)
    create index pan_index on poc_wip2 t
    (extractvalue(value(t),'/WPI/BibPt/@pan'))
    Now when I run the query:
    select extractvalue(value(t),'/WPI/BibPt/@pan')
    from poc_wip2 t
    order by extractvalue(value(t),'/WPI/BibPt/@pan')
    I can see that a full table scan occurs. I cannot get the query to use the index built on the pan attribute.
    I tried adding a INDEX_FFS hint, but this does not work when I name the pan_index, it only works with
    INDEX_FFS(t), in which case the query then uses the primary key index.
    Is it possible to get the query to use the pan_index index?
    Thanks
    Pete

    Hi
    Create a restricted key figure with the ZSE_BPNV1 and mention the values of the attribute and display the values
    Here you can mention your charecteristic and attrribute value both with the key figure
    Assign points if useful
    Regards
    N Ganesh

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

Maybe you are looking for

  • Bought 3 songs on my iPod touch but didn't show up on iTunes. What to do?

    I bought 3 songs yesterday directly from the iTunes Store on my iPod touch. They all downloaded and processed, and I assumed that they showed up on my iPod's music library. Today I checked my iPod to listen to those 3 songs, but only one of them show

  • How to display BITMAP at runtime

    Hey all.... I am new to Photoshop SDK CS2 plugin programming. Can anyone help me to find out any code or any information to display bitmap image on plugin dialog using photoshop API and not the Windows API or MFC. I am just using a simple Dialog exte

  • How to apply hyper link for a particular cell in the column?

    Year 2001 2002 2003 2004 I wanna apply Hyper link for 2001 only! How to achieve this? Can we apply no. of hyper links for a column?

  • Variable selections not appearing while executing query

    hi, am using 3 variables in my query all 3 are ready for input, but still when am testing it in another username, the system does'nt give the selection options and the query is executed automatically. 1 of the variables use company as characteristic.

  • Standard MSS screen for bulk approvals

    Hi Forums, In MSS, is there any screen for approvals (also bulk approval). Currently ESS requests like swipe in swipe out are coming to UWL as work item. Thanks and Regards Sudhir