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

Similar Messages

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

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

Simple SQL Query is not using Bitmap index

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

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

Why bitmap index not working?

I have a table containing 4.2M rows and 16 distinct fs_type_code. So I created a bitmap index ntr_fs_type_code_ind on the column. Then I run the query:
update /*+ INDEX_COMBINE(NTR_FS_TYPE_CODE_IND) */ ntr_CORPALL_20050801 d
set eqt_basket_id = NULL, index_weight = NULL
where
fs_type_code in ('EQGR','EQVG','EQDL')
and eqt_basket_id = equity_symbol
and index_weight = 0;
I clearly tell optimizer to use the bitmap index. But it turns out the optimizer ignore the index and still use full table scan.
When I created regular b-tree index, the same query (without hint) use index scan.
Can anybody tell me why the bitmap index not working here?
Thanks,

<quote>I clearly tell optimizer to use the bitmap index</quote>
You are clearly not doing it right (see bellow). But anyway
1. For frequently modified tables (OLTP type application) you may want to rethink the applicability of bitmap indexes
low cardinality in itself is not enough justification for using bitmap indexes.
2. Your update statement may modify a minority, a majority, or anything in between of the total number of
rows in your table here is no one universal access method which is always better
(if there were one they wouldnt have bothered with coding the rest).
In short, index access is not always the better way.
3. Dont rush into hinting (because that optimizer is such a lousy piece of software)
and if you do, make sure you do it correctly and for the right reasons.
flip@FLOP> create table t as select * from all_objects;
Table created.
flip@FLOP> insert into t select * from t;
30043 rows created.
flip@FLOP> insert into t select * from t;
60086 rows created.
flip@FLOP> insert into t select * from t;
120172 rows created.
flip@FLOP> insert into t select * from t;
240344 rows created.
flip@FLOP> create bitmap index tx on t (object_type);
Index created.
flip@FLOP> exec dbms_stats.gather_table_stats(user,'T',method_opt=>'for all indexed columns',cascade=>true)
PL/SQL procedure successfully completed.
flip@FLOP> select object_type,count(*) from t group by rollup(object_type);
OBJECT_TYPE          COUNT(*)
CONSUMER GROUP             32
DIRECTORY                  32
EVALUATION CONTEXT         16
FUNCTION                 1648
INDEX                   23152
INDEX PARTITION          2048
INDEXTYPE                 128
JAVA CLASS             163024
JAVA RESOURCE            3120
LIBRARY                   224
LOB                        16
MATERIALIZED VIEW          32
OPERATOR                  464
PACKAGE                  5488
PACKAGE BODY               32
PROCEDURE                 640
SEQUENCE                  144
SYNONYM                202512
TABLE                   18816
TABLE PARTITION           880
TRIGGER                  4768
TYPE                    10640
TYPE BODY                  16
VIEW                    42816
                       480688
flip@FLOP> set autotrace on explain
update few rows CBO goes with the index no hinting
flip@FLOP> update t d set object_id=object_id-1 where object_type in ('INDEX','PACKAGE','PACKAGE BODY','TABLE');
47488 rows updated.
Elapsed: 00:00:09.02
Execution Plan
   0      UPDATE STATEMENT Optimizer=CHOOSE (Cost=536 Card=47488 Bytes
          =1044736)
   1    0   UPDATE OF 'T'
   2    1     INLIST ITERATOR
   3    2       BITMAP CONVERSION (TO ROWIDS)
   4    3         BITMAP INDEX (SINGLE VALUE) OF 'TX'
update lots of rows CBO goes with the ft no hinting
flip@FLOP> update t d set object_id=object_id-1 where object_type in ('JAVA CLASS','SYNONYM');
365536 rows updated.
Elapsed: 00:00:25.04
Execution Plan
   0      UPDATE STATEMENT Optimizer=CHOOSE (Cost=638 Card=365536 Byte
          s=8041792)
   1    0   UPDATE OF 'T'
   2    1     TABLE ACCESS (FULL) OF 'T' (Cost=638 Card=365536 Bytes=8
          041792)
update lots of rows wrong hint syntax CBO goes with the ft
flip@FLOP> update /*+ index_combine(tx) */ t d set object_id=object_id-1 where object_type in ('JAVA CLASS','SYNONYM');
365536 rows updated.
Elapsed: 00:00:21.00
Execution Plan
   0      UPDATE STATEMENT Optimizer=CHOOSE (Cost=638 Card=365536 Byte
          s=8041792)
   1    0   UPDATE OF 'T'
   2    1     TABLE ACCESS (FULL) OF 'T' (Cost=638 Card=365536 Bytes=8
          041792)
update lots of rows correct hint syntax CBO goes with the index but was it better than the ft?
flip@FLOP> update /*+ index_combine(d tx) */ t d set object_id=object_id-1 where object_type in ('JAVA CLASS','SYNONYM')
365536 rows updated.
Elapsed: 00:00:25.01
Execution Plan
   0      UPDATE STATEMENT Optimizer=CHOOSE (Cost=1665 Card=365536 Byt
          es=8041792)
   1    0   UPDATE OF 'T'
   2    1     INLIST ITERATOR
   3    2       BITMAP CONVERSION (TO ROWIDS)
   4    3         BITMAP INDEX (SINGLE VALUE) OF 'TX'
flip@FLOP>

Bitmap index not used

I exported/imported a schema. Same Oracle version (10.2.0.3), same server (HP-UX/Itanium).
I have a select that doesn't use a bitmap index in the new database. The same bitmap index is used in the old database.
I run analyze, tried hinting (index, index_combine) nothing helped, I could not force the optimizer to use the index in the new database. Any suggestion?
Thanks

Hi Andras
I would strongly recommend taking a 10053 trace and see what the CBO is up to.
Cheers
Richard Foote
http://richardfoote.wordpress.com/

Using Bitmap Index over db link.

I've a problem with the following query:
select count(*)
from TABLE_A@db_link TABLE_A, TABLE_B
where TABLE_A.ACCEPTTIME = TABLE_B.TIME_B
The above query is doing a full table scan (even after forcing index hints) on TABLE_A which has about 300M records.
TABLE_A is a local table while TABLE_B is remotely accesed using db_link.
There is a bitmap index created on the ACCEPT_TIME field of TABLE_A which is not used by the query. However when I fire this query:
Am I missing something here? How can I make the optimizer use the bitmap index on TABLE_A using remote db_link?
Here is the explain plan for the above query:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT
Optimizer Mode=ALL_ROWS          1           2
SORT AGGREGATE          1      17
NESTED LOOPS          1      17      2
REMOTE     .COPY_STM     1      9      2
     STAG_PLMSPDB1.SMART.COM.PH     SERIAL
INDEX RANGE SCAN     SYSTEM.DIM_TIME_INDX1     1      8      0
Regards,
Raj

Here is a simple case to explain the problem more clearly:
1. dept: database1 (small table dimension with 4 rows)
2. emp: database2 (large table fact with 50K rows)
3. Table emp has bitmap index on column "deptno"
4. Both tables are analyzed with defualt values using DBMS_STATS.GATHER_TABLE AND INDEX STATS
5. DB Link db2 is created from database1 to database2
Observations:
a) On Database2 when the following query is issued:
select count(*) from emp@DATABASE1 emp, dept where emp.deptno = dept.deptno
It does not use the bitmap index.
b) On Database1 when the following query is issued:
select count(*) from emp emp, dept@DATABASE2 where emp.deptno = dept.deptno
It does use the bitmap index since it is available optimizer has this information locally.
My question is how can I make use of the statistics effectively, so that the optimizer knows it has to use the bitmap index present in the remote db.
Regards,
Raj

Bitmap index Vs B-Tree index

Hi All,
Could some one please let me know how Bitmap indexes are useful compared to B-Tree indexes on low-cardinality columns ?.
Thanks,
-Kumar.

>>
As Re: why oracle db 9i optimizer can't choose to use the bitmap index? there are a number of issues with bitmap indexes. Your best bet is to read these three articles by Jonathan Lewis.
It does pay us to understand how the optimizer works with bitmap indexes. I posted some Re: Cost-based optimizer behavior to show how indexes on even very low valued columns can be useful in certain circumstances.
Cheers, APC
Blog : http://radiofreetooting.blogspot.com/

Bitmap indexes and group by

I'm trying to understand why Oracle 8.1.6 sometimes uses bitmap indexes sometimes not.
Of course I have all the statistics, my bitmap indexes are valid and so on.
The problem is this:
- I have a customer table very very large
- I have many columns with bitmap indexes
- I run this statement:
select education_key, count(*)
from customer
group by education_key
and obtain a correct execution plan:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=235 Card=5 Bytes=10)
1 0 SORT (GROUP BY NOSORT) (Cost=235 Card=5 Bytes=10)
2 1 BITMAP CONVERSION (COUNT)
3 2 BITMAP INDEX (FULL SCAN) OF 'CL_EDU'
with the use of the bitmap indexes (only five different values)
- now I want to put a condition on a column
which has a bitmap index.
The new statement is:
select education_key, count(*)
from customer
where age_key = 30
group by education_key
No join, only a scan of a sort of
fact table. In this case Oracle
doesn't use the bitmap index on
education_key:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3458 Card=5 Bytes=20
1 0 SORT (GROUP BY) (Cost=3458 Card=5 Bytes=20)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (Cost=3395 C
ard=18296 Bytes=73184)
3 2 BITMAP CONVERSION (TO ROWIDS)
4 3 BITMAP INDEX (SINGLE VALUE) OF 'CL_AGE'
With this execution plan Oracle has to
read some blocks from the table when I
think that using both the bitmap indexes
the query is faster.
Someone knows why Oracle has this
behaviour? I'm trying to change
many things (also altering statistics
value), but it seems that with a
condition Oracle doesn'use the bitmap
index on the group by column.
null

Hi Michael, what is the address for the lasagne? ....
In init.ora.parms I had 32Mb for bitmap index merge, I suppose it's enough, hovewer I have tried to increase it and nothing changes.
I already use STAR_TRASFORMATION_ENABLED=TRUE.
I have tried with different level of statistics (estimate, compute, also with very precise histograms), always the same
behaviour. I have also tried to change, in a manual way, the statistics in order to change the Oracle behaviour but nothing ...
For this particular statement even if I use the INDEX_COMBINE hint, I mantain the same execution plan.
I use CHOOSE, FIRST_ROWS, ALL_ROWS: always the same behaviour.
I think that Oracle is not able to use a bitmap index on a column involved in a group by when there is another condition in the select.
Hovewer with bitmap indexes, I have many other problems (to read 1% of the table Oracle decides to make a full table scan even if there are the correct bitmap indexes ...).
Many of them are solved using BITMAP_INDEX, but it's difficult to use it in a query tool like Discover or Business Objects because I have to fix the use of INDEX_COMBINE also in situation in which this use is not correct from a performance point of view.
The life with the query optimizer is very hard!
Thank you for your guesses

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);

BITMAP indexes ignored with large IN(...)

I have a fact table with 20 million records joined to a few dimension tables using 10g BITMAP INDEXes but if I add more than two or three items to my SELECT query the optimizer does not choose to use the bitmaps. For example, the first query
SELECT p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date =
TO_DATE( '20010701', 'YYYYMMDD' )
AND p.period_date =
TO_DATE( '20010801', 'YYYYMMDD' )
GROUP BY po.agent_id, p.period_date
definitely uses my BITMAPs as I see that in my EXECUTION PLAN (i.e. I have set autotrace on):
| 0 | SELECT STATEMENT | | 1 | 32
| 1 | HASH GROUP BY | | 1 | 32
|* 2 | FILTER | | |
| 3 | NESTED LOOPS | | 1 | 32
|* 4 | HASH JOIN | | 1 | 19
|* 5 | TABLE ACCESS FULL | PERIOD | 1 | 10
| 6 | TABLE ACCESS BY INDEX ROWID | TRAVEL_HISTORY | 4000K| 34
| 7 | BITMAP CONVERSION TO ROWIDS | | |
| 8 | BITMAP AND | | |
| 9 | BITMAP OR | | |
|* 10 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
|* 11 | BITMAP INDEX SINGLE VALUE| XIF4TRAVEL_HISTORY | |
| 12 | BITMAP MERGE | | |
|* 13 | BITMAP INDEX RANGE SCAN | TRVLHIST_MULTI3_BMIX | |
|* 14 | BITMAP INDEX SINGLE VALUE | XIF1TRAVEL_HISTORY | |
|* 15 | TABLE ACCESS BY INDEX ROWID | AGENT | 1 | 13
|* 16 | INDEX UNIQUE SCAN | XPKAGENT | 1 |
There are only a few hundred records for those two dates, and the above query returns in
less than a second.
However, if I replace the two "period_date =" with IN(...) as:
SELECT /*+ INDEX_COMBINE( Travel_history
AcctHist_MULTI3_bmix
XIF4TRAVEL_HISTORY
XIF1TRAVEL_HISTORY )
p.period_date, po.agent_id, count(*), SUM(ah.charge_amt)
FROM Travel_History ah, Period p, Agent po
WHERE ah.primary_agent_key = po.agent_key
AND ah.period_key = p.period_key
AND po.agent_id IN( 'DGF ', '001MG ' )
AND p.period_date IN (
TO_DATE( '20010701', 'YYYYMMDD' ),
TO_DATE( '20010801', 'YYYYMMDD' ) )
GROUP BY po.agent_id, p.period_date
the execution plan goes back to
| 0 | SELECT STATEMENT | | 747 | 23904 | 45760 (7)|
| 1 | HASH GROUP BY | | 747 | 23904 | 45760 (7)|
|* 2 | FILTER | | | | |
|* 3 | HASH JOIN | | 5000K| 152M| 44897 (5)|
| 4 | MERGE JOIN CARTESIAN| | 860 | 19780 | 26 (0)|
|* 5 | TABLE ACCESS FULL | PERIOD | 4 | 40 | 6 (0)|
| 6 | BUFFER SORT | | 215 | 2795 | 20 (0)|
| 7 | TABLE ACCESS FULL | AGENT | 215 | 2795 | 5 (0)|
| 8 | TABLE ACCESS FULL | TRAVEL_HISTORY | 20M| 171M| 44527 (4)|
If I do a UNION with two SELECTs each with a unique period then the BITMAPs get used. I don't get it.
Is there any reason this would be happening???

There are no bitmap indexes, there is a 64k tablespace header block containing the bitmap of occupied and free extents.
Sybrand Bakker
Senior Oracle DBA

Bitmap Index Not Used in PROD and used in DEV

I am in a situation where in in DEV Bitmap Index is used and in PROD bitmap Index is not used. I checked the count, in PROD I have 10 mil rows and in DEV I have 16 mil rows. Optimizer is CHOOSE and also when I tried to force to use index in PROD, I got higher cost.
Any suggestions why Index is not used in PROD as opposed to DEV

As other says, no guarantee that the same query with same setting OS, ORACLE to produce the same execution plan. Also, as Justin said, dont every take cost as your tuning parameter, pay attention to response time, also, number of logical reads and physical reads. What are the wait events during?
For an index, most important factors are, blevel, clustering_factor, number of distinct values. Clustering actor make a lot of difference. You said, when you force index to use, your performance has gained. If so, why not, why the HINTS there in place? Go ahed and use it, but, after all the R&D. Are the Optimizer* paraemters same on the both databases?
If possible, post the execution plan of the query, with HINT and without HINT as well.
Jaffar

Why CBO don't use function-base index when I use like and bind variable

Hello
I have litle problem with function-base index and like with bind variable.
When I use like with bind variable, the CBO don't use my function-base index.
For example when I create table and index:
ALTER SESSION SET NLS_SORT='BINARY_CI';
ALTER SESSION SET NLS_COMP='LINGUISTIC';
alter session set nls_language='ENGLISH';
-- DROP TABLE TEST1;
CREATE TABLE TEST1 (K1 VARCHAR2(32));
create index test1_idx on test1(nlssort(K1,'nls_sort=BINARY_CI'));
INSERT INTO TEST1
SELECT OBJECT_NAME FROM ALL_OBJECTS;
COMMIT;
When I run:
ALTER SESSION SET NLS_SORT='BINARY_CI';
ALTER SESSION SET NLS_COMP='LINGUISTIC';
SELECT * FROM TEST1 WHERE K1 = 'abcd';
or
SELECT * FROM TEST1 WHERE K1 LIKE 'abcd%';
CBO use index.
PLAN_TABLE_OUTPUT
SQL_ID 4vrmp7cshbvqy, child number 1
SELECT * FROM TEST1 WHERE K1 LIKE 'abcd%'
Plan hash value: 1885706448
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST1 | 2 | 98 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST1_IDX | 2 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TEST1"."SYS_NC00002$">=HEXTORAW('6162636400') AND
"TEST1"."SYS_NC00002$"<HEXTORAW('6162636500') )
but when I run
SELECT * FROM TEST1 WHERE K1 LIKE :1;
CBO don't use index
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 0
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 4122059633
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 89 (100)| |
|* 1 | TABLE ACCESS FULL| TEST1 | 2 | 48 | 89 (3)| 00:00:02 |
Predicate Information (identified by operation id):
1 - filter("K1" LIKE :1)
What should I change to force CBO to use index.
I don't wont use index hint in query.
My oracle version:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

OK. But why if I create normal index (create index test1_idx on test1(K1)) and return to default nls settings this same query use index.
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 0
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 598212486
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
|* 1 | INDEX RANGE SCAN| TEST1_IDX | 1 | 18 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("K1" LIKE :1)
filter("K1" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)
when index is function-base (create index test1_idx on test1(nlssort(K1,'nls_sort=BINARY_CI')))
PLAN_TABLE_OUTPUT
SQL_ID 9t461s1669gru, child number 1
SELECT * FROM TEST1 WHERE K1 LIKE :1
Plan hash value: 4122059633
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 89 (100)| |
|* 1 | TABLE ACCESS FULL| TEST1 | 3 | 54 | 89 (3)| 00:00:02 |
Predicate Information (identified by operation id):
1 - filter("K1" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)
when I create index with upper function "index test1_idx on test1(upper(K1))" the query use index
SELECT * FROM TEST1 WHERE upper(K1) LIKE :1
Plan hash value: 1885706448
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 1 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST1 | 4481 | 157K| 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | TEST1_IDX | 806 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("TEST1"."SYS_NC00002$" LIKE :1)
filter("TEST1"."SYS_NC00002$" LIKE :1)
Note
- dynamic sampling used for this statement (level=2)

Can downloaded oracle9i Enterprise Edition use Bitmap index?

Hello there,
I have a downloaded Oracle9i Enterprise Edition. After I create some bitmap index on a partitioned table, I use the following sql statement to check the bitmap index:
select index_name, index_type, status from user_index;
It tells me that all the statuses of the bitmap indexes are "N/A" (Not availabe). Does that mean I can NOT use bitmap index in this downloaded Enterprise version?
If I must use bitmap indexes, what should I do?
Many thanks in advance!
-wendy

are you creating a local index on the partitioned table?

Peformance tuning of query using bitmap indexes

Hello guys
I just have a quick question about tuning the performance of sql query using bitmap indexes..
Currently, there are 2 tables, date and fact. Fact table has about 1 billion row and date dim has about 1 million. These 2 tables are joined by 2 columns:
Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber
I have query that needs to be run as the following:
Select dates.dayofweek, dates,dates, fact.opened_amount from dates, facts
where Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber and dates.dayofweek = 'monday'.
Currently this query is running forever. I think it is joining that takes a lot of time. I have created bitmap index on dayofweek column because it's low on distinctive rows. But it didn't seem to speed up with the performance..
I'd like to know what other indexes will be helpful for me.. I am thinking of creating another one for companynumber since it also have low distinctive records.
Currently the query is being generated by frontend tools like OBIEE so I can't change the sql nor can't I purge data or create smaller table, I have to what with what I have..
So please let me know your thoughts in terms of performance tunings.
Thanks

The explain plan is:
Row cost Bytes
Select statement optimizer 1 1
nested loops 1 1 299
partition list all 1 0 266
index full scan RD_T.PK_FACTS_SNPSH 1 0 266
TABLE ACCESS BY INDEX ROWID DATES_DIM 1 1 33
INDEX UNIQUE SCAN DATES_DIM_DATE 1 1
There is no changes nor wait states, but query is taking 18 mins to return results. When it does, it returns 1 billion rows, which is the same number of rows of the fact table....(strange?)That's not a bitmap plan. Plans using bitmaps should have steps indicating bitmap conversions; this plan is listing ordinary btree index access. The rows and bytes on the plan for the volume of data you suggested have to be incorrect. (1 row instead of 1B?????)
What version of the data base are you using?
What is your partition key?
Are the partioned table indexes global or local? Is the partition key part of the join columns, and is it indexed?
Analyze the tables and all indexes (use dbms_stats) and see if the statistics get better. If that doesn't work try the dynamic sampling hint (there is some overhead for this) to get statistics at runtime.
I have seen stats like the ones you listed appear in 10g myself.
Edited by: riedelme on Oct 30, 2009 10:37 AM

Why to use a bitmap index

Similar Messages

Maybe you are looking for