Index not being used in access path

Hi,
I have been trying to rewrite a query which currently is taking almost 1min and 25 secs to execute. The database version is 11.1.0.7.
The query is -
SELECT COUNT(1)
FROM TAB1 p
WHERE p.ACODE = 24377
AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
AND p.rflag = 'Y';
The table originally didn't have an index on p.ACODE. So, I created this index and set it to visible and set the optimizer_use_invisible_indexes parameter also to TRUE. I set the monitoring on this index too. Even though I have created the index on the ACODE column, the access path doesn't use it. Can someone please tell me why this is not being used.
Below is the explain plan for the sql stmt and the usage of the index -
I have changed the actual table and column names -
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.ACODE = 24377
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.ACODE = 24377
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3942424611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 214K (2)| 00:42:57 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 214K (2)| 00:42:57 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 209K (2)| 00:41:56 |
|* 4 | TABLE ACCESS FULL | TAB1 | 1 | 32 | 209K (2)| 00:41:55 |
| 5 | INDEX FAST FULL SCAN| PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AKey")
3 - access("PHS"."PKey"="P"."AKey")
4 - filter(TO_NUMBER("P"."ACODE")=24377 AND "P"."rflag"='Y')
20 rows selected.
Elapsed: 00:00:00.03
SQL> select index_name,VISIBILITY from user_indexes where index_name='IDX_TAB1_ACODE';
INDEX_NAME VISIBILIT
IDX_TAB1_ACODE VISIBLE
Elapsed: 00:00:00.01
SQL> show parameter visible
NAME TYPE VALUE
optimizer_use_invisible_indexes boolean TRUE
SQL>
SQL> SELECT v.index_name, v.table_name,
v.monitoring, v.used,
start_monitoring, end_monitoring
FROM v$object_usage v, dba_indexes u
WHERE v.index_name = u.index_name
AND v.index_name = 'IDX_TAB1_ACODE';
INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING
IDX_TAB1_ACODE TAB1 YES NO 05/26/2010 14:13:41
Elapsed: 00:00:00.10
Edited by: user12158503 on May 26, 2010 1:24 PM

Thanks Centinul.
I apologize for posting in both sections. I put it in the Database General too because I thought I originally posted it in the wrong section.
The index was not being used because it was doing the implicit type conversion. When I enclosed it in quotes, it returns the result within a second and it uses the index.(whereas without the index it takes around 1min 25 sec)
Here is the explain plan and execution time after enclosing it in quotes -
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.AKey = '24377'
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2008452282
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 5134 (1)| 00:01:02 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 5134 (1)| 00:01:02 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 60 (2)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 32 | 6 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | IDX_TAB1_AKey | 4 | | 1 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AGILITYKEY")
3 - access("PHS"."PKey"="P"."AGILITYKEY")
4 - filter("P"."rflag"='Y')
5 - access("P"."AKey"='24377')
22 rows selected.
Elapsed: 00:00:00.02
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.AKey = '24377'
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
Elapsed: 00:00:00.52
Can you give me some tips on where I could read about learning to understand the explain plan. I did read a few articles which did help me, but not much. I am looking for something in detail.

Similar Messages

  • Index not being used in group by.

    Here is the scenario with examples. Big table 333 to 500 million rows in the table. Statistics are gathered. Histograms are there. Index is not being used though. Why?
      CREATE TABLE "XXFOCUS"."some_huge_data_table"
       (  "ORG_ID" NUMBER NOT NULL ENABLE,
      "PARTNERID" VARCHAR2(30) NOT NULL ENABLE,
      "EDI_END_DATE" DATE NOT NULL ENABLE,
      "CUSTOMER_ITEM_NUMBER" VARCHAR2(50) NOT NULL ENABLE,
      "STORE_NUMBER" VARCHAR2(10) NOT NULL ENABLE,
      "EDI_START_DATE" DATE,
      "QTY_SOLD_UNIT" NUMBER(7,0),
      "QTY_ON_ORDER_UNIT" NUMBER(7,0),
      "QTY_ON_ORDER_AMT" NUMBER(10,2),
      "QTY_ON_HAND_AMT" NUMBER(10,2),
      "QTY_ON_HAND_UNIT" NUMBER(7,0),
      "QTY_SOLD_AMT" NUMBER(10,2),
      "QTY_RECEIVED_UNIT" NUMBER(7,0),
      "QTY_RECEIVED_AMT" NUMBER(10,2),
      "QTY_REQUISITION_RDC_UNIT" NUMBER(7,0),
         "QTY_REQUISITION_RDC_AMT" NUMBER(10,2),
         "QTY_REQUISITION_RCVD_UNIT" NUMBER(7,0),
         "QTY_REQUISITION_RCVD_AMT" NUMBER(10,2),
         "INSERTED_DATE" DATE,
         "UPDATED_DATE" DATE,
         "CUSTOMER_WEEK" NUMBER,
         "CUSTOMER_MONTH" NUMBER,
         "CUSTOMER_QUARTER" NUMBER,
         "CUSTOMER_YEAR" NUMBER,
         "CUSTOMER_ID" NUMBER,
         "MONTH_NAME" VARCHAR2(3),
         "ORG_WEEK" NUMBER,
         "ORG_MONTH" NUMBER,
         "ORG_QUARTER" NUMBER,
         "ORG_YEAR" NUMBER,
         "SITE_ID" NUMBER,
         "ITEM_ID" NUMBER,
         "ITEM_COST" NUMBER,
         "UNIT_PRICE" NUMBER,
          CONSTRAINT "some_huge_data_table_PK" PRIMARY KEY ("ORG_ID", "PARTNERID", "EDI_END_DATE", "CUSTOMER_ITEM_NUMBER", "STORE_NUMBER")
      USING INDEX TABLESPACE "xxxxx"  ENABLE,
          CONSTRAINT "some_huge_data_table_CK_START_DATE" CHECK (edi_end_date - edi_start_date = 6) ENABLE
    SQL*Plus: Release 11.2.0.2.0 Production on Fri Sep 14 12:11:16 2012
    Copyright (c) 1982, 2010, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> SELECT num_rows FROM user_tables s WHERE s.table_name = 'some_huge_data_table';
      NUM_ROWS                                                                     
    333338434                                                                     
    SQL> SELECT MAX(edi_end_date)
      2    FROM some_huge_data_table p
      3   WHERE p.org_id = some_number
      4     AND p.partnerid = 'some_string';
    MAX(EDI_E                                                                      
    13-MAY-12                                                                      
    Elapsed: 00:00:00.00
    SQL> explain plan for
      2  SELECT MAX(edi_end_date)
      3    FROM some_huge_data_table p
      4   WHERE p.org_id = some_number
      5     AND p.partnerid = 'some_string';
    Explained.
    SQL> /
    PLAN_TABLE_OUTPUT                                                                                  
    Plan hash value: 2104157595                                                                        
    | Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)| Time     |       
    |   0 | SELECT STATEMENT             |             |     1 |    22 |     4   (0)| 00:00:01 |       
    |   1 |  SORT AGGREGATE              |             |     1 |    22 |            |          |       
    |   2 |   FIRST ROW                  |             |     1 |    22 |     4   (0)| 00:00:01 |       
    |*  3 |    INDEX RANGE SCAN (MIN/MAX)| some_huge_data_table_PK |     1 |    22 |     4   (0)| 00:00:01 |       
    SQL> explain plan for
      2  SELECT MAX(edi_end_date),
      3         org_id,
      4         partnerid
      5    FROM some_huge_data_table
      6   GROUP BY org_id,
      7            partnerid;
    Explained.
    PLAN_TABLE_OUTPUT                                                                                  
    Plan hash value: 3950336305                                                                        
    | Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |                    
    |   0 | SELECT STATEMENT   |          |     2 |    44 |  1605K  (1)| 05:21:03 |                    
    |   1 |  HASH GROUP BY     |          |     2 |    44 |  1605K  (1)| 05:21:03 |                    
    |   2 |   TABLE ACCESS FULL| some_huge_data_table |   333M|  6993M|  1592K  (1)| 05:18:33 |                    
    -------------------------------------------------------------------------------                     Why wouldn't it use the index in the group by? If I write a loop to query for different partnerid (there are only three), the whole things takes less than a second. Any help is appreciated.
    btw, I gave the index hint too. Didn't work. Version mentioned in the example.
    Edited by: RPuttagunta on Sep 14, 2012 11:24 AM
    Edited by: RPuttagunta on Sep 14, 2012 11:26 AM
    the actual names are 'scrubbed' for obvious reasons. Don't worry, I didn't name the tables in mixed case.

    Jonathan,
    Thank you for your input. Forgot about this issue since ended up creating an MV since, the view was slower. But either way, I am curious. Here are the results for your questions.
    SQL> SELECT last_analyzed,
      2         blocks
      3    FROM user_tables s
      4   WHERE s.table_name = 'huge_data';
    LAST_ANAL     BLOCKS
    14-MAY-12    5869281
    SQL> SELECT last_analyzed,
      2         leaf_blocks
      3    FROM user_indexes i
      4   WHERE i.table_name = 'huge_data';
    LAST_ANAL LEAF_BLOCKS
    14-MAY-12     2887925
    SQL>It looks like stale statistics from the last_analyzed, but, they really aren't. This is a development database and that was the last time around which it was refreshed. And the stats are right (at least the approx_no_of_blocks and num_rows etc).
    No other data came into the table after.
    Also,
    1). I thought I don't have any particular optimizer parameters, but, checking back I do. fastfull_scan_enabled = false. Could that be it?
    SQL> SELECT a.name,
      2         a.value,
      3         a.display_value,
      4         a.isdefault,
      5         a.isses_modifiable
      6    FROM v$parameter a
      7   WHERE a.name LIKE '\_%' ESCAPE '\';
    NAME                           VALUE                          DISPLAY_VALUE   ISDEFAULT       ISSES
    _disable_fast_validate         TRUE                           TRUE            FALSE           TRUE
    _system_trig_enabled           TRUE                           TRUE            FALSE           FALSE
    _sort_elimination_cost_ratio   5                              5               FALSE           TRUE
    _b_tree_bitmap_plans           FALSE                          FALSE           FALSE           TRUE
    _fast_full_scan_enabled        FALSE                          FALSE           FALSE           TRUE
    _index_join_enabled            FALSE                          FALSE           FALSE           TRUE
    _like_with_bind_as_equality    TRUE                           TRUE            FALSE           TRUE
    _optimizer_autostats_job       FALSE                          FALSE           FALSE           FALSE
    _connect_by_use_union_all      OLD_PLAN_MODE                  OLD_PLAN_MODE   FALSE           TRUE
    _trace_files_public            TRUE                           TRUE            FALSE           FALSE
    10 rows selected.
    SQL>As, you might have guessed, I am not the dba for this db. Should pay more attention to these optimizer parameters.
    I know why we had to set connectby_use_union_all hint (due to a bug in 11gR2).
    Also, vaguely remember something about the disablefast_validate (something about another major db bug in 11gR2 again), but, not sure why those other parameters are set.
    2). Also, I have tried this
    SQL> SELECT /*+ index_ss(huge_data_pk) gather_plan_statistics*/
      2   MAX(edi_end_date),
      3   org_id,
      4   partnerid
      5    FROM huge_data
      6   GROUP BY org_id,
      7            partnerid;
    MAX(EDI_E     ORG_ID PARTNERID
    2 rows
    SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null,null,'ALLSTATS LAST'));
    PLAN_TABLE_OUTPUT
    SQL_ID  f3kk8skdyvz7c, child number 0
    SELECT /*+ index_ss(huge_data_pk) gather_plan_statistics*/
    MAX(edi_end_date),  org_id,  partnerid   FROM huge_data  GROUP BY
    org_id,           partnerid
    Plan hash value: 3950336305
    | Id  | Operation          | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT   |          |      1 |        |      2 |00:05:11.31 |    5905K|   5897K|    |  |          |
    |   1 |  HASH GROUP BY     |          |      1 |      2 |      2 |00:05:11.31 |    5905K|   5897K|   964K|   964K| 2304K (0)|
    |   2 |   TABLE ACCESS FULL| hug_DATA |      1 |    333M|    334M|00:04:31.44 |    5905K|   5897K|    |  |          |
    16 rows selected.But, then, I tried this too.
    SQL> alter session set "_fast_full_scan_enabled"=true;
    Session altered.
    SQL> SELECT MAX(edi_end_date),
      2         org_id,
      3         partnerid
      4    FROM hug_data
      5   GROUP BY org_id,
      6            partnerid;
    MAX(EDI_E     ORG_ID PARTNERID
    2 rowsAnd this took around 5 minutes too.
    PS: This has nothing to do with original question, but, it is plausible to derive the 'huge_data' table name from the sql_id? Just curious.

  • Index not being used in Oracle 11g

    Hi,
    I executed an SQL in Oracle 9i based on a Materialized View with an index. Execution plan shows it used Index and did Range scan. But the same query if I executed in Oracle 11g, it did full table scan and ignored the index. Finally, I used /*+Index*/ hint to tell compiler to use the index. Can anyone tell why it happended like this.
    below is the query.
    SELECT TYPE,NAME,PARENT_ID,CHILD_ID,UNIT_OF_MEASURE,QUANTITY,POSITION_NUMBER
    FROM MVIEW_BOM_CHILD_ATTRIBUTES
    WHERE BREAKDOWN_LIMIT = 'FALSE'
    CONNECT BY PRIOR CHILD_ID = PARENT_ID START WITH PARENT_ID IN ('7325','34676','10121','35154','34370','4909','5494','28714','2273','22551','36465','35416','7148','34774',' 23290','18225','24415','35774','34772','20108','19072','8134','14688','31751','12669','26450','34716','768 4','26004','8770','34001','32614','3816','19801','30329','13822','15784','9296','17147','35423','6181','3477 3','18683','20780','35191','17990','7788','1559','7691','35449','34640','35432','35829','14161','9412','2039 2','593','23744','15741','35850','4177','36420','34695','33027','34655','31315','13552','23089','14025','901 2','22930','36182','13413','13839','32502','2392','19666','35183','32174','35170','20545','14344','29190','1 8163','19124','35448','32171','23498','2694','31101','4357','30421','35826','17976','13218','34770','35778' ,'16112','36408','34797','3294','9600','23524','3663','36412','34674','26715','2886','3204','15928','4510','8 112','27232','14966','35217','6281','1610','16359','25906','10262','3291','35777','11789','34675','24208','1 0093','28479','2928','23396','19702','32716','29813','2536','2349','34639','18610','35175','9796','26915','6 041','4745','34718','17946','3285','34308','9451','29689','17903','34642','35166','4630','35760','35761','34 696','27958','5912','35549','17695','31595','8028','24020','16025','8004','6430','36391','3580','32433','354 94','27368','15801','35583','35488','18807','34180','26626','20629','34767','14771','28746','34728','4948',' 34355','14000','34734','35820','36449','4904','11136','35177','27740','8016','13883','36402','35233','2614 7','21089','33152','35162','11320','32843','7336','34654','35602','32026','35582','24500','10573','33778','1 651','22781','25784','30124','10798','15930','28652','1513','745','35415','30404','21990','20872','2272','16 273','4234','35601','35581','22088','15543','3362','7713','35431','34719','27710','33104','20482','16801','1 686','35658','16545','32681','8722','20046','8950','34799','31605','21299','19572','445','35489','35656','35 546','7414','13369','35455','35434','35438','19383','10591','24698','14607','25715','27913','1046','15511',' 36386','6801','25134','2717','2083','35288','15851','14538','35398','11575','35156','35435','4232','36380',' 18406','32862','20879','5695','4229','24132','7081','35420','34694','22474','30047','29352','34735','2305',' 36409','18040','13472','31481','29246').
    Thanks

    SBH wrote:
    My doubt is only that is it possible that a SQL query with same index proprties uses different access path to execute. Is it dependent on oracle version also.
    Yes, it is possible.
    It is even possible on the same Oracle version - look at simple examples:
    case 1
    create table test as
    select level l, 'test' test from dual
    connect by level < 1000;
    create index test_ix on test(l);
    explain plan for
    select * from test where l < 50;
    select * from table(dbms_xplan.display);
    Plan hash value: 1408842701
    | Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |         |    49 |   931 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TEST    |    49 |   931 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | TEST_IX |    49 |       |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("L"<50)
    Note
       - dynamic sampling used for this statement (level=2)case 2
    drop table test;
    create table test as
    select * from (
      select level l, 'test' test from dual
      connect by level < 1000
    ) order by dbms_random.value(0,100);
    create index test_ix on test(l);
    explain plan for
    select * from test where l < 50;
    select * from table(dbms_xplan.display);
    Plan hash value: 1357081020
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |    49 |   931 |     3   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| TEST |    49 |   931 |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("L"<50)
    Note
       - dynamic sampling used for this statement (level=2)The same query on the same table containing the same data in it. And the same index.
    The only difference is records order in the table.
    In the first case CBO decided that index range scan would be reasonable.
    In the second case CBO preferred FTS as less costly.

  • Index not being used (again)

    Dear All,
    Having real trouble these days with the indexes.
    I have a query below:
    SELECT MAX(A.ID) PRID,TIMEPERIODID,RESOURCEID
                          FROM   TIMESHEET A, TIMEPERIOD B
                          WHERE A.STATUS IN (1,3,4) AND A.ISADJUSTMENT = 0  
                             AND A.timeperiodid = B.id
                             AND TRUNC(B.PSTART)>=TRUNC(NEXT_DAY(SYSDATE-28,'MONDAY'))
                             GROUP BY TIMEPERIODID,RESOURCEID
    The explain plan for this query is as below:
    Plan     COST
    SELECT STATEMENT       2720
    SORT GROUP BY      2720
      HASH JOIN       2520
       TABLE ACCESS FULL TIMEPERIOD     2
       TABLE ACCESS FULL TIMESHEET     2516As you can see, table access full on timesheet table. However, I have an index on timeperiodid column of the table. Despite using it as hint, the index is not being used. Is it that indexes are not used with GROUP BY?
    Please help.
    Thanks,

    and the explain plan:
    Plan
    SELECT STATEMENT  ALL_ROWSCost: 18,747  Bytes: 105  Cardinality: 1                                                    
         34 SORT GROUP BY  Cost: 18,742  Bytes: 105  Cardinality: 1                                               
              33 FILTER                                          
                   21 NESTED LOOPS  Cost: 18,727  Bytes: 105  Cardinality: 1                                     
                        18 HASH JOIN  Cost: 18,722  Bytes: 415  Cardinality: 5                                
                             11 TABLE ACCESS BY INDEX ROWID TIMEENTRY Cost: 14  Bytes: 144  Cardinality: 9                           
                                  10 NESTED LOOPS  Cost: 15,980  Bytes: 15,552  Cardinality: 243                      
                                       8 HASH JOIN  Cost: 15,588  Bytes: 1,344  Cardinality: 28                 
                                            3 HASH JOIN  Cost: 4,050  Bytes: 24,876,930  Cardinality: 829,231            
                                                 1 TABLE ACCESS FULL TEAM Cost: 3,394  Bytes: 879,444  Cardinality: 48,858       
                                                 2 INDEX FAST FULL SCAN NON-UNIQUE TASK2 Cost: 396  Bytes: 11,656,104  Cardinality: 971,342       
                                            7 VIEW index$_join$_003 Cost: 10,376  Bytes: 24,981,984  Cardinality: 1,387,888            
                                                 6 HASH JOIN  Cost: 15,588  Bytes: 1,344  Cardinality: 28       
                                                      4 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT1 Cost: 3,835  Bytes: 24,981,984  Cardinality: 1,387,888 
                                                      5 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT4 Cost: 3,835  Bytes: 24,981,984  Cardinality: 1,387,888 
                                       9 INDEX RANGE SCAN NON-UNIQUE TIMEENTRY5 Cost: 2  Cardinality: 12                 
                             17 VIEW USER25. Cost: 2,741  Bytes: 553,812  Cardinality: 29,148                           
                                  16 SORT GROUP BY  Cost: 2,741  Bytes: 1,107,624  Cardinality: 29,148                      
                                       15 HASH JOIN  Cost: 2,540  Bytes: 1,107,624  Cardinality: 29,148                 
                                            13 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1  Bytes: 140  Cardinality: 10            
                                                 12 INDEX RANGE SCAN NON-UNIQUE TIMEPERIOD2 Cost: 1  Cardinality: 2       
                                            14 TABLE ACCESS FULL TIMESHEET Cost: 2,537  Bytes: 12,040,224  Cardinality: 501,676            
                        20 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1  Bytes: 22  Cardinality: 1                                
                             19 INDEX UNIQUE SCAN UNIQUE TIMEPERIOD1 Cardinality: 1                           
                   32 NESTED LOOPS  Cost: 5  Bytes: 75  Cardinality: 1                                     
                        29 NESTED LOOPS  Cost: 4  Bytes: 63  Cardinality: 1                                
                             27 NESTED LOOPS  Cost: 2  Bytes: 37  Cardinality: 1                           
                                  25 NESTED LOOPS  Cost: 2  Bytes: 31  Cardinality: 1                      
                                       23 TABLE ACCESS BY INDEX ROWID OBS_TYPES Cost: 1  Bytes: 18  Cardinality: 1                 
                                            22 INDEX UNIQUE SCAN UNIQUE OBS_TYPES_U2 Cardinality: 1            
                                       24 INDEX RANGE SCAN NON-UNIQUE PROJECT_INDX1 Cost: 1  Bytes: 13  Cardinality: 1                 
                                  26 INDEX UNIQUE SCAN UNIQUE PROJECTS_PK Bytes: 6  Cardinality: 1                      
                             28 INDEX RANGE SCAN NON-UNIQUE OBS_ASSOCIATIONS_N3 Cost: 2  Bytes: 26  Cardinality: 1                           
                        31 TABLE ACCESS BY INDEX ROWID OBS_UNITS Cost: 1  Bytes: 12  Cardinality: 1                                
                             30 INDEX UNIQUE SCAN UNIQUE OBS_UNITS_U1 Cardinality: 1                           

  • Newly created index not being used

    Hello friends,
    I am observing that a newly created index on a z table with mandt & a new field is not being used. I have already rebuild index & updated stats for table.
    when we query on this table with where clause having same 2 fields mandt & other.. we expected this index to be used. This table is very large. What more i can do now ?
    In trace/SQL session, we can see it is going full table scan.. and takes very long time.
    this new field contain no data as of now for all existing rows. Is this the reason ? or sometihng else ?
    SQL Statement
    SELECT
    FROM
      "ABSA"
    WHERE
      "MANDT" = :A0 AND "ZABCD" = :A1
    Execution Plan
    Explain from v$sql_plan not possible ->  Explain from PLAN_TABLE is displayed !
    No values in v$sql_plan for Address: 0000000166710240 Hash_value:  3891403872 Child_number:  0 Sql_id:
    SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
            1 TABLE ACCESS FULL ZABSA
              ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
              Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
              Filter Predicates
    NONUNIQUE  Index   ZABSA~Z01
    Column Name                     #Distinct
    MANDT                                          1
    ZABCD                                         1
    thanks & regards
    ashish
    Edited by: ashish vikas on Mar 3, 2012 9:05 PM

    ashish vikas wrote:
    > Execution Plan
    > Explain from v$sql_plan not possible ->  Explain from PLAN_TABLE is displayed !
    > No values in v$sql_plan for Address: 0000000166710240 Hash_value:  3891403872 Child_number:  0 Sql_id:
    >
    >  SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
    >
    >         1 TABLE ACCESS FULL ZABSA
    >           ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
    >           Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
    >           Filter Predicates
    >
    > NONUNIQUE  Index   ZABSA~Z01
    > Column Name                     #Distinct
    > MANDT                                          1
    > ZABCD                                         1
    Hi,
    with this WHERE clause, both columns just one distinct value, the Full Table Scan is indded the best approach, beside
    the point you only need a check to evaluate a value is NOT in the result.
    In this case you should HINT the statement to the new index, because the DB will always assume that this index is non-selective.
    Volker

  • Linguistic index not being used

    I am using 10G database and am having an issue that my linguistic index is not being used during sorting.
    Any help will be appreciated.
    Table structure.
    create table TEST
    ID CHAR(256) not null,
    NAME VARCHAR2(100) not null,
    DESIGNATION VARCHAR2(200)
    alter table TEST add constraint ID primary key (ID)
    create index TEST_IDX on TEST (NLSSORT(NAME,'nls_sort=''GENERIC_M'''))
    Number of rows - 1 million
    Query being run.
    alter session set nls_sort='Generic_M';
    select * from test order by name;
    Explain plan
    PLAN_TABLE_OUTPUT
    | 0 | SELECT STATEMENT | | 1001K| 270M| | 70194 (1)| 00:14:0
    3 |
    | 1 | SORT ORDER BY | | 1001K| 270M| 579M| 70194 (1)| 00:14:0
    3 |
    | 2 | TABLE ACCESS FULL| TEST | 1001K| 270M| | 9163 (1)| 00:01:5
    0 |
    --------------------------------------------------------------------------------

    I don't think that's true, at least with the nls_sort function. I'm running into the same problem now, and I've traced with and without the use of the index, and it's definitely better with the index.
    Here it is, not using the index:
    SQL> select * from test where col2='sfs';
    no rows selected
    Execution Plan
    Plan hash value: 1357081020
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:00:01 |
    |* 1 | TABLE ACCESS FULL| TEST | 1 | 366 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    1 - filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('7366730
    0') )
    Note
    - dynamic sampling used for this statement
    Statistics
    87 recursive calls
    0 db block gets
    21 consistent gets
    0 physical reads
    0 redo size
    339 bytes sent via SQL*Net to client
    327 bytes received via SQL*Net from client
    1 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    0 rows processed
    And here it is WITH the index:
    SQL> select /*+ index_asc(test index1) */ * from test where col2='adsfas';
    no rows selected
    Execution Plan
    Plan hash value: 2960817241
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
    |
    | 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:0
    0:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 366 | 2 (0)| 00:0
    0:01 |
    |* 2 | INDEX FULL SCAN | INDEX1 | 1 | | 1 (0)| 00:0
    0:01 |
    Predicate Information (identified by operation id):
    2 - access(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
    0') )
    filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
    0') )
    Note
    - dynamic sampling used for this statement
    Statistics
    11 recursive calls
    0 db block gets
    7 consistent gets
    0 physical reads
    0 redo size
    339 bytes sent via SQL*Net to client
    327 bytes received via SQL*Net from client
    1 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    0 rows processed
    Oddly enough, the optimizer chooses not to use the index on this example table I created.

  • Index not being used in Select statement

    Friends
    I have the following SQL statement:
    SELECT
    a.acct,
    a.date_field,
    UPPER(b.feegroup) feegrp,
    SUM (a.fee1) fee1,
    SUM (a.fee2) fee2,
    SUM (a.fee3) fee3
    FROM table1 a, table2 b
    WHERE 1 = 1
    AND a.fee_id = b.fee_id
    GROUP BY a.acct, a.date_field, b.feegroup;
    Both the tables have index on fee_id column. When I run the explain plan for this statement, I am getting the following output:
    Operation | Option | Object Name | Position
    SELECT STATEMENT | | | 560299
    HASH | GROUP BY| |1
    TABLE ACCESS | FULL| table2 | 1
    TABLE ACCESS | FULL| table1 | 2
    Why Oracle is not using the index?
    Edited by: darshilm on Dec 10, 2009 3:56 PM

    The proposed plan is the optimal according to your current conditions in the "where clause" where you have only the equality join condition and therefore the CBO can use HASH JOIN. Using any kind of index access would just increase the amount of required work unless you would add some very restrictive conditions which will select rows from relatively small amount of blocks. Here I have to mention that what really counts in the CBO cost calculation is the amount of blocks accessed and not the number of rows. The "currency" for I/O in Oracle is a block and not a row. CBO always uses an assumption that there is nothing in the buffer cache and it will have to perform a physical read for every block.
    How many blocks will actually be accessed depends on the data distribution. It can happen that every single row that you have to retrieve resides in a different block and although you access only 1000 rows out of a million row table you would have to visit almost every block of that table. For such a situation a FULL TABLE SCAN is the best access path and Oracle will use multiblock I/O for that. On the other side you can have those 1000 rows only in a few blocks and then the index access would be the most appropriate one. For index access Oracle uses single block I/O. Usually the actual situation is somewhere between this two extreme situations. But you can run some tests by yourself and see when an index access will be replaced by a full table scan while you will make your predicates less selective.
    HTH, Joze
    Co-author of the forthcoming book "Expert Oracle Practices"
    http://www.apress.com/book/view/9781430226680
    Oracle related blog: http://joze-senegacnik.blogspot.com/
    Blog about flying: http://jsenegacnik.blogspot.com/
    Blog about Building Ovens, Baking and Cooking: http://senegacnik.blogspot.com

  • Why is index not being used?

    I need some help in trying to work out why an index isn't being used. I hope someone here can help.
    Table definition for ACT_TOTALS includes
    STARTTIME TIMESTAMP(6)
    There is an index on to_char(starttime, 'YYYY-MM-DD HH24')
    There is a vew definition ACT_TOTALS_HOURLY2 which includes
    select to_char(starttime, 'YYYY-MM-DD HH24') STARTTIMSE
    from ACT_TOTALS
    group by to_char(starttime, 'YYYY-MM'DD HH24'), TRANSTYPE
    I have run a query
    select starttime from ACT_TOTALS_HOURLY2
    where starttime <= to_char(sysdate, 'YYYY-MM-DD HH24');
    The table access comes out as full despite there being > 2 million rows in the table.
    The predicate looks like
    TO_CHAR(INTERNAL_FUNCTION(''STARTTIME''), 'YYYY-MM-DD HH24')<= ..........
    I thinkg the INTERNAL_FUNCTION is an implicit cast from DATE to TIMESTAMP.
    Can anyone please throw any light on why the index on the table wouldn't be used in this case?
    Thanks in advance for any help.

    Can you supply a test case for that?
    This is what I have done to engeneer your case
    drop table t1;
    create table t1 (n1 number, d1 date, STARTTIME TIMESTAMP(6));
    insert into t1(n1,d1, starttime)  select rownum, trunc(sysdate) + rownum, sysdate
    from dual connect by level <= 2e6;
    create or replace view t1_v as select n1, d1, to_char(starttime, 'YYYY-MM-DD HH24') starttimse
    from t1;
    SQL> explain plan for
      2  select starttimse from t1_v
      3  where starttimse <= to_char(sysdate, 'YYYY-MM-DD HH24');
    Explained.
    SQL> select * from table(dbms_xplan.display);
    Plan hash value: 838529891
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      |   109K|  1394K|  2004  (14)| 00:00:12 |
    |*  1 |  TABLE ACCESS FULL| T1   |   109K|  1394K|  2004  (14)| 00:00:12 |
    Predicate Information (identified by operation id):
       1 - filter(TO_CHAR(INTERNAL_FUNCTION("STARTTIME"),'YYYY-MM-DD
                  HH24')<=TO_CHAR(SYSDATE@!,'YYYY-MM-DD HH24'))
    Note
       - dynamic sampling used for this statement
    SQL> create index t1_ind on t1 (to_char(starttime, 'YYYY-MM-DD HH24'));
    Index created.
    SQL> explain plan for
      2  select starttimse from t1_v
      3  where starttimse <= to_char(sysdate, 'YYYY-MM-DD HH24');
    Explained.
    SQL> select * from table(dbms_xplan.display);
    Plan hash value: 3884685049
    | Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT |        |   109K|  1394K|    68   (2)| 00:00:01 |
    |*  1 |  INDEX RANGE SCAN| T1_IND |   109K|  1394K|    68   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access(TO_CHAR(INTERNAL_FUNCTION("STARTTIME"),'YYYY-MM-DD
                  HH24')<=TO_CHAR(SYSDATE@!,'YYYY-MM-DD HH24'))
    Note
       - dynamic sampling used for this statement
    The above selects are done against the view t1_v.
    While the following one is done against the table t1
    SQL> set autotrace traceonly explain
    SQL> select starttime from t1
      2  where starttime <= to_char(sysdate, 'YYYY-MM-DD HH24');
    Execution Plan
    Plan hash value: 838529891
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      | 29875 |   379K|  1790   (4)| 00:00:11 |
    |*  1 |  TABLE ACCESS FULL| T1   | 29875 |   379K|  1790   (4)| 00:00:11 |
    Predicate Information (identified by operation id):
       1 - filter("STARTTIME"<=TO_TIMESTAMP(TO_CHAR(SYSDATE@!,'YYYY-MM-DD
                  HH24')))
    If you can post a clear test case of your issue may be one of us can help you
    Best regards
    Mohamed Houri
    www.hourim.wordpress.com

  • LINGUISTIC index not being used when it should be - why?

    We have Oracle 10g R2 and using the case insensitve feature within the database. We have 2 schemas, one called 'app' and the other 'crs'. The crs schema owns the all the tables, views etc and has granted select on its objects to schema app.
    We have a 'after log on' trigger on schema app the executes the following:
    execute immediate 'alter session set NLS_COMP=LINGUISTIC';
    execute immediate 'alter session set NLS_SORT=BINARY_CI';
    We have a people table containing 180,000 records defined as:
    person_id varchar2(10) not null and primary key,
    surname varchar2(200) not null
    We have the following indexes on this table:
    create index my_indx1 on people (nlssort(person_id, 'NLS_SORT=BINARY_CI'));
    create index my_indx2 on people (nlssort(surname, 'NLS_SORT=BINARY_CI'));
    create index my_indx3 on people (upper(surname));
    So, when I run the following SQL as schema CRS:
    select * from people where upper(surname) = 'xxxxxx'
    it uses my_indx3 which is what I expect.
    But when I run the same sql as schema app it does a full table scan when I expected it to use my_indx2. Why isn't it using my_indx2 - what am I missing here - do I need to include a hint into the sql?????
    Cheers
    John.

    The first test is always to check the execution plan - especially the predicate section. Based on your description, a simple test case showed Oracle transforming the predicate as follows:
    Before "alter session":
    access (UPPER("SURNAME")='xxxxxx')After "alter session"
    filter(NLSSORT(UPPER("SURNAME"),'nls_sort=''BINARY_CI''')=HEXTORAW('78787878787800') )Note the 'upper' that is still present - it looks like you need to create your index on the expression:
    (nlssort(upper(surname), 'NLS_SORT=BINARY_CI'))Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • Index not being used even with hint

    For this query, I'm getting a full table scan even when specifying a hint:
    SELECT /*+ index_ffs (d ix_dunsno_dnb_store_data ) */7 as s_no, 'Number of DNB Records' as name, count(distinct( dnb_duns_number)) as value
    FROM dnb_store_data d
    However, this query uses an index fast full scan, even without the hint:
    select count(distinct(dnb_duns_number)) as value from dnb_store_data
    Anyone have any ideas??? I'm on oracle 10.2.0.4

    SQL> create table myt1 as select * from dba_objects;
    Table created.
    SQL> create index myt1$objname on myt1(object_name);
    Index created.
    SQL> explain plan for select /*+ FULL(myt1) */ count(distinct object_name) from myt1;
    Explained.
    SQL> SET LINESIZE 130
    SQL> SET PAGESIZE 0
    SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
    Plan hash value: 1763129885
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |    66 |    49   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY     |      |     1 |    66 |            |          |
    |   2 |   TABLE ACCESS FULL| MYT1 | 11020 |   710K|    49   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    13 rows selected.
    SQL> explain plan for select /*+ INDEX_FFS( MYT1$OBJNAME myt1) */ count(distinct object_name) from myt1;
    Explained.
    SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
    Plan hash value: 2781289525
    | Id  | Operation             | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |              |     1 |    66 |    18   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY        |              |     1 |    66 |            |          |
    |   2 |   INDEX FAST FULL SCAN| MYT1$OBJNAME | 11020 |   710K|    18   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    13 rows selected.
    SQL> explain plan for select /*+ INDEX_FFS( MYT1$OBJNAME myt1) */ 7 as ttt, count(distinct object_name) from myt1;
    Explained.
    SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
    Plan hash value: 1763129885
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |      |     1 |    66 |    49   (0)| 00:00:01 |
    |   1 |  SORT GROUP BY     |      |     1 |    66 |            |          |
    |   2 |   TABLE ACCESS FULL| MYT1 | 11020 |   710K|    49   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    13 rows selected.
    SQL> explain plan for select 7 as ttt, ct from ( select count(distinct object_name) ct from myt1);
    Explained.
    SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY);
    Plan hash value: 4000407046
    | Id  | Operation              | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT       |              |     1 |    13 |    18   (0)| 00:00:01 |
    |   1 |  VIEW                  |              |     1 |    13 |    18   (0)| 00:00:01 |
    |   2 |   SORT GROUP BY        |              |     1 |    66 |            |          |
    |   3 |    INDEX FAST FULL SCAN| MYT1$OBJNAME | 11020 |   710K|    18   (0)| 00:00:01 |
    Note
       - dynamic sampling used for this statement
    14 rows selected.So, problem is with '7 as ttt'.

  • Index not being used

    Hi all,
    10.2.0.1
    I have a query of the kind
    SELECT   DISTINCT a.trea_code,
                      a.class1,
                      a.class2,
                      a.class3,
                      a.class4,
                      a.other,
                      a.gross_pay,
                      b.trea_name
    FROM     (SELECT   trea_code,
                       Count(CASE
                               WHEN empl_code = '1'
                               THEN emp_code
                             END) class1,
                       Count(CASE
                               WHEN empl_code = '2'
                               THEN emp_code
                             END) class2,
                       Count(CASE
                               WHEN empl_code = '3'
                               THEN emp_code
                             END) class3,
                       Count(CASE
                               WHEN empl_code = '4'
                               THEN emp_code
                             END) class4,
                       Count(CASE
                               WHEN empl_code = '5'
                               THEN emp_code
                             END) other,
                       Sum(CASE
                             WHEN empl_code BETWEEN '1' AND '5'
                             THEN gross_pay
                           END) gross_pay
              FROM     mon_act
              WHERE    v_no IS NOT NULL
                       --and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
                       AND To_char(upto_date,'MONYYYY') = 'JAN2010'
              GROUP BY trea_code
              ORDER BY 1) a,
             treasury.trea_mast b
    WHERE    a.trea_code = b.trea_code
    ORDER BY 1 The trea_code,emp_code,upto_date column of mon_Act are primary key indexed[pk_monact].
    Upon creating a function based index on to_char(upto_date,'MONYYYY'), oracle uses the function based index.
    But If query as
    SELECT   DISTINCT a.trea_code,
                      a.class1,
                      a.class2,
                      a.class3,
                      a.class4,
                      a.other,
                      a.gross_pay,
                      b.trea_name
    FROM     (SELECT   trea_code,
                       Count(CASE
                               WHEN empl_code = '1'
                               THEN emp_code
                             END) class1,
                       Count(CASE
                               WHEN empl_code = '2'
                               THEN emp_code
                             END) class2,
                       Count(CASE
                               WHEN empl_code = '3'
                               THEN emp_code
                             END) class3,
                       Count(CASE
                               WHEN empl_code = '4'
                               THEN emp_code
                             END) class4,
                       Count(CASE
                               WHEN empl_code = '5'
                               THEN emp_code
                             END) other,
                       Sum(CASE
                             WHEN empl_code BETWEEN '1' AND '5'
                             THEN gross_pay
                           END) gross_pay
              FROM     mon_act
              WHERE    v_no IS NOT NULL
                       and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
                       --AND To_char(upto_date,'MONYYYY') = 'JAN2010'
              GROUP BY trea_code
              ORDER BY 1) a,
             treasury.trea_mast b
    WHERE    a.trea_code = b.trea_code
    ORDER BY 1  Oracle does not use the index pk_monact and does a n expansive full scan of mon_act.
    The statistics are upto date.
    Even if i use a hint as /*+ mon_act pk_monact */ in the outer query,it does not use an index.
    Why it is ignoring the index based on primary key?

    Hi !
    Which execution plan to use , CBO decides based on its own calculations which depends on ... many things . You can
    analize CBO decision with activating event 10053 and analyzing output ( trace file )
    ALTER SESSION SET EVENTS='10053 trace name context forever, level 1';  --- activate tracing
    -- run your query
    ALTER SESSION SET EVENTS '10053 trace name context off'; --- deactivate tracing
    analize recent trace file using TKPROF T

  • Performance issue - Index not being used

    Hi,
    I have the following scenario
    - I have a table Account with a PK -Account_ID, for which there is a index PK_ACCOUNT_ID_IDX
    - Another table Account_fact has a PK - Account_ID, Month_Year, for which there is a index PK_ACCOUNT_FACT_IDX
    I have a join in these two table. The query is
    select a.ACCOUNT_ID, b.Cost
    From Account a, Account_fact b
    Where a.account_id = b.Account_id
    and a.Include_flag = 'Y'
    The explain plan for this query tells me its doing a Full table scan and not using the index and the cost of query is very high.
    Can any one suggest what is wrong here.
    Regards
    Deepak

    >> Shud I be creating a bit map index.
    Bit map index is not for this case.
    http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96533/data_acc.htm#8131
    Also bitmaps are very dangerous for Transactional tables. They are not meant for them.
    As I told you in this case create index on all the columns you are using in the query.
    For example INCLUDE_FLAG, ACCOUNT_ID in ACCOUNT table
    ACCOUNT_ID, COST in the other table.
    But keep in mind that if you are selecting any other column from these tables then again it might opt for full table scan......

  • How to tell which Indexes are not being used?

    We are a large development shop and have many customers. Our database design is very generic so that it works for all of our customers. Each night we use an SSIS ETL process to bring down large amounts of data from the iSeries into SQL. One
    particularily large customer takes a very long time and we are looking for ways to speed up thier data import and transformation. I would like to see which indexes he does not use and possibly remove them. Each night we fully repopulate hundreds of staging
    and ods tables and incrementally delete and repopulate the days work for a handful of history type tables. Removing some indexes off of the large tables could make a big impact. 
    How can i tell which indexes the customer does not use?

    > IDENTIFYING UNUSED INDEXES IN A SQL SERVER DATABASE 
       Just because an index is not being used does not necessarily mean it should be removed.
    > Index This: All About SQL Server Indexes
    sp_BlitzIndex
    José Diz     Belo Horizonte, MG - Brasil

  • An index can not being used and still afect a query performance?

    Hi i have a query with a high cost so i created two indexes, A and B, to improve its performance.
    After the creation of the indexes when i reviewed the execution plan of the query the cost had been reduced, but i noticed that the index B is not being used,
    and if i try to force the query to use index B with a HINT the cost increases, so i decided to drop the index B.
    Once i droped the index B i checked the execution plan again and then i noticed that the cost of the query increased, if i recreate the index B the explain plan
    shows a lower cost even though its not being used by the execution plan.
    Does anyone know why is this happening?
    An index can, not being used by the execution plan and still affect a query performance?

    user11173393 wrote:
    Hi i have a query with a high cost so i created two indexes, A and B, to improve its performance.
    After the creation of the indexes when i reviewed the execution plan of the query the cost had been reduced, but i noticed that the index B is not being used,
    and if i try to force the query to use index B with a HINT the cost increases, so i decided to drop the index B.
    Once i droped the index B i checked the execution plan again and then i noticed that the cost of the query increased, if i recreate the index B the explain plan
    shows a lower cost even though its not being used by the execution plan.
    Does anyone know why is this happening?
    An index can, not being used by the execution plan and still affect a query performance?You said that is what is happening, & I believe you.

  • Structured XMLIndex is not being used

    I have a table defined as "TABLE OF XMLTYPE" with XML Binary storage with a structured XMLIndex under Oracle 11.2.0.3.4. The query that I am using on this table is virtually the same as the XMLIndex, but it's not being used. I searched the forums for similar issues and found this:
    XMLIndex is not getting used
    However, the post is a couple of years old, and I think that the solution was really specific to the problem. Not that mine isn't. ;)
    Per the forum guidelines, the data/DDL is confidential, and should not be posted, so I opened a SR for it - SR 3-7160281751.
    May I please have some help understanding why the structured XMLIndex is not being used?
    Thanks...

    OK, I did the best I could to clean this up. The last query in this script is the one not using the index. The tables "book_master" and "book_join_temp" are populated, though I didn't include the data here. Do you see anything wrong?
    --Create tables...
    CREATE TABLE book_master OF XMLTYPE
    XMLTYPE STORE AS SECUREFILE BINARY XML
    VIRTUAL COLUMNS
      isbn_nbr AS ( XmlCast(
                    XmlQuery('declare namespace plh="http://www.mrbook.com/InventoryData/Listing";
                              declare namespace invtdata="http://www.mrbook.com/Inventory";
                              /invtdata:INVENTORY/plh:LIST/plh:ISBN_NBR'
                              PASSING object_value RETURNING CONTENT) AS VARCHAR2(64)) ),
      book_id AS ( XmlCast(
                    XmlQuery('declare namespace plh="http://www.mrbook.com/InventoryData/Listing";
                              declare namespace invtdata="http://www.mrbook.com/Inventory";
                              /invtdata:INVENTORY/plh:LIST/plh:BOOK_ID'
                              PASSING object_value RETURNING CONTENT) AS VARCHAR2(64)) )
    CREATE GLOBAL TEMPORARY TABLE book_join_temp
       isbn_nbr VARCHAR2(64),
       book_id VARCHAR2(64),
       row_num INT,
       PRIMARY KEY(row_num)
    ) ON COMMIT DELETE ROWS;
    --Create indices....
    CREATE INDEX bkm_xmlindex_ix ON book_master (OBJECT_VALUE) INDEXTYPE IS XDB.XMLIndex PARAMETERS ('PATH TABLE path_tab');
    BEGIN
       DBMS_XMLINDEX.registerParameter(
          'myparam',
          'ADD_GROUP GROUP book_record
             XMLTable bk_idx_tab
             XmlNamespaces(''http://www.mrbook.com/InventoryData/Listing'' AS "plh",
                      ''http://www.mrbook.com/Inventory'' AS "invtdata",
                      ''http://www.mrbook.com/BookInfo'' AS "idty",
                      ''http://www.mrbook.com/References'' AS "lclone",
                      ''http://www.mrbook.com/Publishing'' AS "trd",
                      ''http://www.mrbook.com'' AS "mrbook"),
             ''/invtdata:INVT_DATA''
               COLUMNS
                    xml_id    RAW(16)     PATH ''/@XML_ID'',
                    isbn_nbr  VARCHAR(64) PATH ''/plh:LIST/plh:ISBN_NBR'',
                    book_id   VARCHAR(64) PATH ''/plh:LIST/plh:BOOK_ID'',
                    seller_loc_id NUMBER(13,0) PATH ''/plh:LIST/plh:SELLER_LOC_ID'',
                    catg_typ_cd NUMBER(7,0) PATH ''/idty:BK_INFO/idty:CATG_TYP_CD'',
                    CTRY_MKT_LOC NUMBER(7,0) PATH ''/idty:BK_INFO/idty:CTRY_MKT_LOC'',
                    bk_out_of_print_cd NUMBER(7,0) PATH ''/idty:BK_INFO/idty:BK_OUT_OF_PRINT_CD'',
                    reprint_isbn_nbr VARCHAR2(64) PATH ''/idty:BK_INFO/idty:REPRINT_ISBN_NBR'',
                    reprint_book_id VARCHAR2(64) PATH ''/idty:BK_INFO/idty:REPRINT_BOOK_ID'',
                    orig_ed_isbn_nbr VARCHAR2(64) PATH ''/lclone:REFERENCES/lclone:PRINT[child::lclone:PRINT_TYP_CD="160"]/lclone:ISBN_NBR'',
                    orig_ed_book_id VARCHAR2(64) PATH ''//lclone:REFERENCES/lclone:PRINT[child::lclone:PRINT_TYP_CD="160"]/lclone:BOOK_ID'',
                    last_mod_dt TIMESTAMP PATH ''/node()[local-name()="LAST_MOD_DT"]'',
                    subject_catg_code  NUMBER(7) PATH ''/idty:BK_INFO/idty:SUBJECT_CATG_CODE[child::idty:CATG_REF_LVL=1]/idty:SUBJECT_CATG_CODE'',
                    catg_code VARCHAR2(48) PATH ''/idty:BK_INFO/idty:SUBJECT_CATG_CODE[child::idty:CATG_REF_LVL=1]/idty:CATG_CODE'',
                    pub_summ  XMLType   PATH ''/trd:PUB_SUMM'' VIRTUAL
                XMLTable trd_summ_entr_ix
                XmlNamespaces(''http://www.mrbook.com/InventoryData/Listing'' AS "plh",
                      ''http://www.mrbook.com/Inventory'' AS "invtdata",
                      ''http://www.mrbook.com/BookInfo'' AS "idty",
                      ''http://www.mrbook.com/References'' AS "lclone",
                      ''http://www.mrbook.com/Publishing'' AS "trd",
                      ''http://www.mrbook.com'' AS "mrbook"),
                   ''/trd:PUB_SUMM/trd:PUBLC'' PASSING pub_summ
                COLUMNS
                    pub_yrmo  VARCHAR2(6) PATH ''/@PUBLC_YRMO''
    END;
    ALTER INDEX bk_xmlindex_ix PARAMETERS('PARAM myparam');
    CREATE INDEX ejt_isbn ON book_join_temp(isbn_nbr);
    CREATE INDEX ejt_book ON book_join_temp(book_id);
    --Using the PATH table instead of structured index???
    SELECT
        ej.row_num,
        e.xml_id,
        e.isbn_nbr,
        e.book_id,
        e.seller_loc_id,
        e.seller_loc_id AS mkt_seller_id,
        e.catg_typ_cd,
        e.CTRY_MKT_LOC,
        e.bk_out_of_print_cd,
        e.reprint_isbn_nbr,
        e.reprint_book_id,
        e.orig_ed_isbn_nbr,
        e.orig_ed_book_id,
        g.OBJECT_VALUE AS invt_data
    FROM
        book_master g,
        book_join_temp ej,
        XmlTable(
        XmlNamespaces('http://www.mrbook.com/InventoryData/Listing' AS "plh",
                      'http://www.mrbook.com/Inventory' AS "invtdata",
                      'http://www.mrbook.com/BookInfo' AS "idty",
                      'http://www.mrbook.com/References' AS "lclone",
                      'http://www.mrbook.com' AS "mrbook"),
          '/invtdata:INVENTORY'
        PASSING g.OBJECT_VALUE
        COLUMNS
           xml_id PATH '@XML_ID',
           isbn_nbr VARCHAR2(64) PATH 'plh:LIST/plh:ISBN_NBR',
           book_id VARCHAR2(64) PATH 'plh:LIST/plh:BOOK_ID',
           seller_loc_id NUMBER PATH 'plh:LIST/plh:SELLER_LOC_ID',
           catg_typ_cd NUMBER PATH 'idty:BK_INFO/idty:CATG_TYP_CD',
           CTRY_MKT_LOC NUMBER PATH 'idty:BK_INFO/idty:CTRY_MKT_LOC',
           bk_out_of_print_cd NUMBER PATH 'idty:BK_INFO/idty:BK_OUT_OF_PRINT_CD',
           reprint_isbn_nbr NUMBER PATH 'idty:SUBJ_DTL/idty:SUCSR_DUNS_NBR',
           reprint_book_id NUMBER PATH 'idty:SUBJ_DTL/idty:SUCSR_SUBJ_ID',
           orig_ed_isbn_nbr VARCHAR2(64) PATH '/lclone:REFERENCES/lclone:PRINT[child::lclone:PRINT_TYP_CD="160"]/lclone:ISBN_NBR',
           orig_ed_book_id VARCHAR2(64) PATH '/lclone:REFERENCES/lclone:PRINT[child::lclone:PRINT_TYP_CD="160"]/lclone:BOOK_ID'
    ) e
    WHERE
         ej.isbn_nbr = e.isbn_nbr
    OR  ej.book_id = e.book_id;

Maybe you are looking for

  • How can I delete or reset bookmark data in iCloud?

    How can I delete or re-set bookmark data in iCloud. I have sync'd with blank from safari, then re-loaded safari with new list. Sync to phone works fine. Now everytime I re-enable backup to iCloud 500 duplicates are made and all old folders restored.

  • Printing Flex Chart Application with FireFox 2 and later

    Hi, I have problem with printing functionality in FireFox. The print preview shows an empty page. So the user ends with this step and thinks no print is available. Another problem is when I try to print directly not the whole application will be prin

  • I cannot import movies or videos into itunes library

    please help me out in viewing videos in itunes asap...!!! this is the screenshot of thng tht appears when i open for movies in my itunes library.. i have videos of mp4 format which are coverted using converte and itunes which i use in my pc is latest

  • Instance where Secondary Cost Element Linked to GL also

    Hello Gurus, What are the instances where secondary cost element is a GL also. Regards Rohit

  • Merge to HDR Pro Issue

    Hello all, I'm going to give you as much information about this as possible in the first instance so we don't have to play post tag. In using Merge to HDR Pro in CS5, the process will allow me to pick the images I wish to use and being the process fo