Qeury not using the bitmap index

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

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

Similar Messages

  • Optimizer is not using the right index

    Hi gurus,
    there's something I understand. If someone can explains, it'll be greatly appreciated.
    Env:
    10gR2 on Redhat AS
    The
    SQL> desc stock_detail
    Name Null? Type
    NO NOT NULL NUMBER(15)
    BP_CODE NOT NULL VARCHAR2(10)
    STOC_CAT_CODE NOT NULL VARCHAR2(6)
    BUIL_CODE NOT NULL VARCHAR2(8)
    LOCA_CODE NOT NULL VARCHAR2(8)
    LOCA_SUB_CODE NOT NULL VARCHAR2(6)
    ITEM_NO NOT NULL NUMBER(8)
    QTY NOT NULL NUMBER(6)
    DEFAULT_SHELF NOT NULL VARCHAR2(1)
    CREATION_DATE NOT NULL DATE
    CREATION_USER NOT NULL VARCHAR2(8)
    CM_NO NUMBER(15)
    LANDING_COST NUMBER(11,2)
    SUPPLI_COST NUMBER(11,2)
    RMA_DEADLINE DATE
    MOD_USER VARCHAR2(8)
    MOD_DATE DATE
    RECEP_DATE DATE
    NOTE VARCHAR2(2000)
    FLAG VARCHAR2(1)
    REFUS VARCHAR2(1)
    STOC_MOVE_REAS_CODE VARCHAR2(6)
    I have many indexes on this table. (like 5 or 6).
    There's one with item + business_unit (lets say INDEX_A)
    And there's one with item + category + business_unit (lets say INDEX_B)
    The following sql is always using the wrong index
    select nvl(sum(sd.qty),0)
    from stock_detail sd, location lo
    where sd.item_no = 419261 <- In INDEX_A & INDEX_B
    and sd.STOC_CAT_CODE='REG' <- In INDEX_B
    and sd.bp_code = 'TECMTL' <- In INDEX_A & INDEX_B
    and sd.buil_code <> 'TRANSIT'
    and sd.buil_code = lo.buil_code
    and sd.loca_code = lo.code
    and sd.loca_sub_code = lo.sub_code
    and nvl(lo.restricted, 'N') = 'Y';
    This SQL always use the INDEX_A. INDEX_B is far better.
    Stats of the index uactually used (INDEX_A):
    Last Analyzed 2007-10-18 22:04:38
    Blevel 1
    Distinct Keys 72124
    Clustering Factor 105368
    Leaf Blocks 339
    Average Leaf Blocks Per Key 1
    Average Data Blocks Per Key 1
    Number of Rows 110285
    Sample Size 110285
    Stats of the index I want to be used (INDEX_B)
    Last Analyzed 2007-10-18 22:04:46
    Blevel 2
    Distinct Keys 77407
    Clustering Factor 103472
    Leaf Blocks 551
    Average Leaf Blocks Per Key 1
    Average Data Blocks Per Key 1
    Number of Rows 110285
    Sample Size 110285
    Is there a way to use the right index without adding a hint?
    Thanks in advance.
    Message was edited by:
    (made a mistkae on the stats of index B)

    I assume the execution path is a nested loop driving of the table with the constant inputs.
    The key difference in the stats is that the second index has a blevel of 2. I'd guess that the cost of using the first index is 1, and the cost of using the second index is three.
    The basic cost of accessing a table through an index is:
    blevel +
    index selectivity (ix_sel) * leaf blocks +
    table selectivity (ix_sel_with_filtering) * clustering_factor.
    However, if the blevel is 1, then Oracle ignores it.
    Your index and table selectivities in both cases are 1/distinct_keys (since this is 10.2)
    The numbers involved with the leaf block and clustering factor calculations are so small (and similar) that the difference of 2 in the add-on for the blevel is the deciding factor.
    According to the statistics, though, the choice of index shouldn't make much difference to the performance, since the number of rows (and blocks) visited is likely to be the same. However, if you have an uneven distribution of values for individual columns, you may need a histogram on that column so that the optimizer can see the effect it has on the expected work.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    P.S. I suppose it's probably fair to mention that I wrote a pretty good book about how the optimizer works: http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

  • Why Oracle not using the correct indexes after running table stats

    I created an index on the table and ran the a sql statement. I found that via the explain plan that index is being used and is cheaper which I wanted.
    Latter I ran all tables stats and found out again via explain plan that the same sql is now using different index and more costly plan. I don't know what is going on. Why this is happening. Any suggestions.
    Thx

    I just wanted to know the cost using the index.
    To gather histograms use (method_opt is the one that causes the package to collect histograms)
    DBMS_STATS.GATHER_SCHEMA_STATS (
    ownname => 'SCHEMA',
    estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
    block_sample => TRUE,
    method_opt => 'FOR ALL COLUMNS SIZE AUTO',
    degree => 4,
    granularity => 'ALL',
    cascade => TRUE,
    options => 'GATHER'
    );

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

  • Query not using the index

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

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

  • Why is Oracle not using the index??

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

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

  • Why does it not use the index?

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

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

  • Why my select is not using the index

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

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

  • Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? Difference between Enterprise and SE?

    We’re seeing the following issue: sql - Can Oracle be forced to use the spatial index for sdo_filter in combination with an or clause? - Stack Overflow (posted by a colleague of mine) and are curious to know if this behaviour is due to a difference between standard and enterprise, or could we doing something else wrong in our DB config.?
    We have also reproduced the issue on the following stacks:
    Oracle SE One 11.2.0.3 (with Spatial enabled)
    Redhat Linux 2.6.32-358.6.2.el6.x86_64 #1 SMP Thu May 16 20:59:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
    11.2.0.3.0 Standard Edition and 11.2.0.4.0 Standard Edition (both with Spatial enabled)
    Microsoft Windows Server 2003R2 Standard x64 Edition
    However, the SQL works fine if we try it on Oracle 11.2.0.3.0 *Enterprise* Edition.
    Any help or advice would be much appreciated.
    Kindest Regards,
    Kevin

    In my experience sdo_filter ALWAYS uses the spatial index, so that's not the problem. Since you did not provide the explain plans, we can't say for sure but I think yhu is right: Standard Edition can't use the bitmap operations, and thus it'll take longer to combine the results of the two queries (because the optimizer will surely split this OR up in two parts, then combine them).
    BTW: when asking questions about queries here, it would be nice if you posted the queries here as well, so that we do not have to check another website in order to see what you are doing. Plus it will probably get you more answers, because not everyone can be bothered to click on that link. It would also have been nice if you had posted your own answer on the other post here as well, because my recommendation would have been to use union all - but since you already found that out for yourself my recommendation would have been a little late.

  • Partitioned IOT of Object Type - mapping table not allowed for bitmap index

    Hi,
    looks like a feature available for standard Partitioned IOTs is not supported for object based tables, namely the MAPPING TABLE construct to support secondary local bitmap indexes.
    Can you confirm behaviour is as expected/documented?
    If so, is a fix/enhancement to support mapping table for object-based Partitioned IOTs in the pipeline?
    Results for partition-wise load using pipelined table function are very good, look-ups across tens of millions of rows are excellent.
    Environment = Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    OS = Oracle Enterprise Linux Server release 5.2 (Carthage) 2.6.18 92.el5 (32-bit)
    Here's the potted test-case...
    1) First the non object based Partitioned IOT - data is range-partitioned across the alphabet
    CREATE TABLE IOT_Table (
    textData VARCHAR2(10),
    numberData NUMBER(10,0),
    CONSTRAINT IOT_Table_PK PRIMARY KEY(textData))
    ORGANIZATION INDEX MAPPING TABLE PCTFREE 0 TABLESPACE Firewire
    PARTITION BY RANGE (textData)
    (PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
    NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
    SQL> table IOT_TABLE created.
    2) Create the local secondary bitmap index utilising the underlying mapping table
    CREATE BITMAP INDEX IOT_Table_BMI1 ON IOT_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    SQL> bitmap index IOT_TABLE_BMI1 created.
    3) Quick test to confirm all ok
    SQL> INSERT INTO IOT_Table VALUES ('ABC123',100);
    SQL> 1 rows inserted.
    SQL> SELECT * FROM IOT_Table;
    TEXTDATA NUMBERDATA
    ABC123     100
    4) Now create a minimal object type to use as the template for object table
    CREATE TYPE IOT_type AS OBJECT
    textData VARCHAR2(10 CHAR),
    numberData NUMBER(10,0)
    ) FINAL
    SQL> TYPE IOT_type compiled
    5) Attempt to create an object-based range partitioned IOT, including MAPPING TABLE clause as per step (1)
    CREATE TABLE IOTObj_Table OF IOT_type (textData PRIMARY KEY)
    OBJECT IDENTIFIER IS PRIMARY KEY ORGANIZATION INDEX
    MAPPING TABLE -- we'd like to use this feature to enable use of Bitmap Indexes...
    PCTFREE 0 TABLESPACE Firewire
    PARTITION BY RANGE (textData)
    (PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
    PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
    NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
    This errors out with the following...
    SQL Error: ORA-25182: feature not currently available for index-organized tables
    25182. 00000 - "feature not currently available for index-organized tables"
    *Cause:    An attempt was made to use one or more of the following feature(s) not
    currently supported for index-organized tables:
    CREATE TABLE with LOB/BFILE/VARRAY columns,
    partitioning/PARALLEL/CREATE TABLE AS SELECT options,
    ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
    *Action:   Do not use the disallowed feature(s) in this release.
    6) Re-running the create table statement in step 5 without the MAPPING TABLE clause works fine. Not surprisingly an attempt to create a secondary local bitmap index on this table fails as there's no mapping table, like so...
    CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    CREATE TABLE with LOB/BFILE/VARRAY columns,
    partitioning/PARALLEL/CREATE TABLE AS SELECT options,
    ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
    *Action:   Do not use the disallowed feature(s) in this release.
    CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL
    Error at Command Line:99 Column:13
    Error report:
    SQL Error: ORA-00903: invalid table name
    00903. 00000 - "invalid table name"
    7) Creating a secondary local b-tree index is fine, like so...
    SQL> CREATE INDEX IOTObj_Table_I1 ON IOTObj_Table (numberData)
    LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
    index IOTOBJ_TABLE_I1 created.
    8) A quick test to ensure object table ok...
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
    SQL> 1 rows inserted.
    SQL> SELECT * FROM IOTObj_Table;
    TEXTDATA NUMBERDATA
    DEF456     500

    Thanks Dan,
    the intention is to range partition based on the initial character, so A* -> Text_Part_A, B* -> Text_Part_B, and so on.
    Here's an example, using an empty IOTObj_Table as created previously.
    1) Set up & confirm some test data (two 'D's, one 'N', and two 'Z's)
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DDD111',510));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('N3000',515));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('ZZ1212',520));
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
    SQL> COMMIT;
    SQL> SELECT * FROM IOTObj_Table;
    TEXTDATA NUMBERDATA
    DDD111     510
    DEF456     500
    N3000     515
    Z111X     530
    ZZ1212     520
    2) Just to prove our IOT is enforcing the Primary Key based on the TextData attribute, try to insert a duplicate
    SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
    Error starting at line 141 in command:
    INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530))
    Error report:
    SQL Error: ORA-00001: unique constraint (OCDataSystems.SYS_IOT_TOP_84235) violated
    00001. 00000 - "unique constraint (%s.%s) violated"
    *Cause:    An UPDATE or INSERT statement attempted to insert a duplicate key.
    For Trusted Oracle configured in DBMS MAC mode, you may see
    this message if a duplicate entry exists at a different level.
    *Action:   Either remove the unique restriction or do not insert the key.
    3) Now confirm that our data has been slotted into the range-based partition we expect using the PARTITION clause of SELECT...
    - The two 'D's...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_D);
    TEXTDATA NUMBERDATA
    DDD111     510
    DEF456     500
    - The single 'N'...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_N);
    TEXTDATA NUMBERDATA
    N3000     515
    - The two 'Z's...
    SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_Z);
    TEXTDATA NUMBERDATA
    Z111X     530
    ZZ1212     520
    4) And to wrap up confirm an empty partition
    SELECT * FROM IOTObj_Table PARTITION (Text_Part_W);

  • Why to use a bitmap index

    I've read that it may be usefull to create a bitmap index on low cardinality columns. And this is my doubt. Let's suppose I have a gender column on a table. This certainly has got a very low cardinality 'cause I can only have M or F in it and so it could be a column to create a bitmap index on. The question is: does it make sense to create an index on such a column since probably I had better to make a full scan table having 50% of probabilities of finding a record with gender = 'F' or = 'M' rather than using an index? What I mean is that it doesn't seem to make sense creating an index on a low cardinality column, regardless of traditional or bitmap index, am I right? Therefore why and when should I learn to use bitmap indexes?
    Thanks!

    The power of bitmap indexes comes when you can combine multiple bitmaps.
    Thus, if you have multiple query predicates on the same table ANDed together, and each has a bitmap index that can be used, the optimizer can choose to do a BITMAP AND on the indexes.
    If your table has a Gender column (and only 2 (or 3 ?)) genders and queries will be only by Gender, a Bitmap index to fetch rows from the table wouldn't help. The Bitmap index can still be used to do a COUNT by Gender.
    Updating the Bitmap index on Gender would be an expensive operation so you should plan to NOT have a high rate of concurrent DML.
    Hemant K Chitale

  • Trying to make use of bitmap indexes

    Hello!
    I have a table that contains about 16 mill rows and each night about
    60.000-70.000 rows are proccessed against the table so that part of the rows
    is updated and another part is inserted.
    The table contains three IDEAL columns for bitmap indexes the first of which
    may have only two, the second three and the third four distinct values.
    I was planning to change the index type on these columns to BITMAP but
    Oracle doesnt recommend to build BITMAP indexes on heavily updated or inserted
    columns.
    So the only use of bitmap indexes turns out to be read-only tables.
    From the other hand a sloution might be dropping indexes before the load and rebuilding them after the load has completed what can lead to often tablespace fragmentations.
    So, the question is how can I use bitmap indexes in a case like this one?
    What are wayouts?
    Thank you very mcuh for the reply.

    >
    The table contains three IDEAL columns for bitmap indexes the first of which
    may have only two, the second three and the third four distinct values.
    Contrary to popular legend, and possibly contrary even to the manuals and Metalink, these columns are NOT necessarily ideal for bitmap indexes. Consider a query with:
        col1 = '1_of_2'
    and col2 = '1_of_3'
    and col3 = '1_of_4'You have a total of 24 possible combinations. Given your 16M rows, this means that on average the optimizer will expect to collect about 670.000 rows spread across something like 100,000 to 130,000 blocks. Under these circumstances you may find that Oracle doesn't use the indexes anyway (unless you fool it by fiddling with parameters like the optimizer_index_cost_adj, and that's generally a bad idea) - and if the model is a reasonable description of the actual data it probably shouldn't use the indexes.
    There are various special circumstance that might make the indexes effective for querying, though. (Note - at this point I'm not considering the impact on inserts, updates and deletes). The most obvious example is where all three columns each have at least one very repetitive value and all your queries are trying to find data for the remaining "rare" values. If this is the case then you need to index the columns and collect histograms on the columns so that the optimiser can model the data correctly; and then you may also need to modify your SQL to ensure that your queries against these columns always use literal values, not bind variables.
    If some of your queries are supposed to return small amounts of data, there are various mechanisms you could use to do this efficiently. If your queries are always going to return large amounts of data, then there are other strategies that are likely to be more appropriate.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • Is there any way to have an ipad wifi 3G but not use the 3G (therefore avoiding the extra data plan costs) and just use the wifi?

    i am looking to buy an ipad 2 or the new ipad (preferably 32gb) but dont want to buy the 3G version as i have unlimited data usage in my mobile phone plan, i know the wifi only ipad is generally cheaper, but i was wondering if there was a way to buy the ipad with 3G capabilities but not use the 3G and avoid the cost of paying the extra unnecessary data plan? (I know this is a really weird question but i have the opportunity to buy a 3G ipad and was curious of the possibility? any help would be greatly appreciated. cheers

    Yes to your questions.
    You can download a complete iPad User Guide here: http://manuals.info.apple.com/en/ipad_user_guide.pdf
    If you want an iPad 2 32GB it will have to be a refurb model. The only new iPas 2 is 16GB.
    What are all the differences between the iPad 3rd Gen and the iPad 2? Is the iPad 2 worth the cost savings?
    http://everymac.com/systems/apple/ipad/ipad-faq/differences-between-ipad-3rd-gen -2012-ipad-2-2011.html
    What are all the differences between the iPad 3rd Gen models? Which should I buy?
    http://everymac.com/systems/apple/ipad/ipad-faq/differences-between-ipad-3rd-gen -early-2012-models.html
    Should I Buy a New iPad? Or an iPad 2?
    http://www.maclife.com/article/blogs/should_i_buy_new_ipad_or_ipad_2
    iPad 3 vs iPad 2 vs iPad 1- Feature comparisons with iOS 5
    http://ipadhelp.com/ipad-help/ipad-3-vs-ipad-2/
    iPad Q&A
    http://www.everymac.com/systems/apple/ipad/ipad-faq/differences-between-ipad-3rd -gen-early-2012-models.html
    A Few Questions (and Answers) About the New iPad
    http://pogue.blogs.nytimes.com/2012/03/15/a-few-questions-and-answers-about-the-   new-ipad/?ref=personaltechemail&nl=technology&emc=edit_ct_20120315
    New iPad: A Polishing of the Old
    http://www.nytimes.com/2012/03/15/technology/personaltech/the-new-ipad-is-much-t he-same-only-better.html?nl=technology&emc=edit_ct_20120315
    iPad 1, 2 and New Specifications
    http://www.everymac.com/systems/apple/ipad/index-ipad-specs.html
    16GB vs 32GB vs 64GB: Which new iPad storage capacity should you get?
    http://www.imore.com/2012/03/08/16gb-32gb-64gb-ipad-capacity/
    How much content will fit on my iPod or iPhone?
    http://support.apple.com/kb/HT1867
    If you think you may get an iPad 2:
    Refurbished iPad Prices
    http://store.apple.com/us/browse/home/specialdeals/ipad
    New 16GB iPad 2 Prices
    http://store.apple.com/us/browse/home/shop_ipad/family/ipad/select_ipad2
    When iOS 6 comes out in the fall, the iPad 3 will get Siri, but the iPad 2 won't.
     Cheers, Tom

  • Query don't use the right index when using bind variables

    Hi people !
    I need some help because I have an issue with a query that don t use the right Indexes as it should
    First of all, I have mainly three tables :
    ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
    ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
    with quantity of packages prepared for each product (approximately 10 000 000 Records)
    PRODUCT : Tables that contains the products (approximately 50 000 Records)
    When I launch the query with hard coded values, it brings back response very fast
    because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
    (with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
    NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
    the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
    NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
    It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
    Here is the correct explain plan when I execute the query with hard coded values :
    SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
    AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = 'ADIDAS'
    AND PRODUCT.CODE = 1234
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    4 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    4 TABLE ACCESS BY INDEX ROWID ORDER
    777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
    2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
    Now the problem is when the query is used in a Cursor with bind variables.
    It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
    to actually filter on a short period of time (only one day).
    So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
    Here is the bad explain plan :
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    722 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
    2 TABLE ACCESS BY INDEX ROWID ORDER
    1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
    Now I have found two solutions to this problem :
    1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
    2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
    For example :
    QUERY :=
    'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
    AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = :CUSTOMER
    AND PRODUCT.CODE = :CODE ';
    These two solutions work but Number 1 is bad in theory because it uses a Hint
    and Number 2 may be difficult to code.
    So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
    Thank you very much for support
    Edited by: remaï on Apr 1, 2009 4:08 PM

    What version of oracle you have? CBO work is different in 9i and 10g.
    Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
    (As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
    ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
    The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
    Edited by: JustasVred on Apr 1, 2009 10:10 AM

  • Why can I not use the channel name, which is obtained from the function of DAQmx Task, as the input of the channel name for the function of Get Channel Information of DAQ?

    Why can I not use the channel name, which is obtained from the function of DAQmx Task, as the input of the channel name for the function of Get Channel Information of DAQ?

    Not a lot of details here, but my guess is this isn't working for you because you are wiring in the task to the Active Channels Property and not the actual Channel Name. I have attatched a screenshot of what I believe you are trying to do. The Task has 2 channels in it, so I need to index off one of the channels and wire it into the active channels input of the Channel Property node. Then I can read information about that channel
    Attachments:
    channel_name.JPG ‏69 KB

Maybe you are looking for

  • Balance between Vendor balance and GL

    Hi Experts, We are in the process on confirming the balance between the subledger recon account and the vendor balances.However,we find that there is a huge difference between the total balances of all the vendors and subledger and the balances do no

  • UNIX "ln" command and Mac OS X applications

    I have an application hardwired to read 4 files with specific names, in a specific location. I want to move the files to the Users/Shared folder so other users can access them; however, the application must still be able to open and save them, meanin

  • Import images into Photoshop Elements Photo Organizer from Safari

    Hi, I recently bought Adobe Photoshop Elements 9 for Mac. Safari is my default browser. I wonder, has anyone seen an extension or add-on to Apple Safari 5.0 that creates a context dialog that would allow one to import an image from a web page into th

  • Messed up screen resolution

    Hi everyone, I have a first-generation Apple TV. I'm using it with an older Sony television (flat-screen, but not LCD or plasma or anything of that nature). I used component cables to connect it to the television. I was once able to see the list of r

  • ISight in FCP-YES

    While I'm trying to get my HVR-A1U working in Final Cut, I discovered the really easy way to get an isight to work in Final Cut. For some reason my camera isn't being recognized my Final Cut, so I refreshed AV devices (option+F12) and all of a sudden