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

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

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

How to make use of the index in my manual within Acrobat

I've created an index in my FrameMaker book and would like it to be of use when it's converted to PDF.
An index is most useful if it's provided in hard copy. How can I make it useful in Acrobat?
Do I do something within Frame or Acrobat or both?
Also, when I convert my document to PDF with bookmarks, a bookmark does not appear for my index.
I have Acrobat 9 Pro.
Thank you!

In the book file, right-click the index file and select Set up Standard Index. In the subsequent dialog box, select Create Hypertext Links. Click Set. Update the book.
When you print the book, click PDF Setup. In the Links tab, select Create Named Destinations for All Elements and Paragraphs.
To make the Index appear in the bookmarks, check that its paragraph format style is included in the Include paragraphs list in the PDF setup dialog box.
Hope this helps,
Van

Can a query make use of an Index on concat column ?

Hi sql gurus,
We will develope application on a database as below ( simplified ) :
create table invoice (doc_no varchar2(30), cust_code varchar2(10), amount number (12,2));
create table debit_memo (doc_code varchar2(6), doc_no varchar2(24), cust_code varchar2(10), amount number (12,2));
create table credit_memo (doc_code varchar2(6), doc_no varchar2(24), cust_code varchar2(10), amount number (12,2));
create view v_ar_transaction as
select doc_no, cust_code, amount from invoice
union
select doc_code||doc_no, cust_code, amount from debit_memo
union
select doc_code||doc_no, cust_code, amount from credit_memo
The question is :
If I have query like this :
select * from v_ar_transaction where doc_no = :pdoc_no
Can it use the index built on the tables ?
What kind of index that will help the above query to be efficient ?
Thank you for your help,
xtanto

create view v_ar_transaction as
select doc_no, cust_code, amount from invoice
union
select doc_code||doc_no, cust_code, amount from
debit_memo
union
select doc_code||doc_no, cust_code, amount from
credit_memo
he question is :
If I have query like this :
select * from v_ar_transaction where doc_no =
:pdoc_no
an it use the index built on the tables ?
What kind of index that will help the above query to
be efficient ?I'd try:
doc_no for invoice
function based index doc_code||doc_no for debit_memo and credit_memo
As a side note - do you really need UNION or UNION ALL?
Isn't important where the transaction comes from?
Gints Plivna
http://www.gplivna.eu

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/

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

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

Local Bitmap Index Confusions

Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
For instance, in future, some rows get inserted in an existing partition where the local bitmap index is present, so then I should once again rebuild the index on that partition, because in case of insert Oracle would have disabled it?
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Thanks and best regards

The more I know, the more I know that how little I know. Thanks Jonathan for a very insightful answer. Please clarify some points and thanks for your valuable feedback.
Jonathan Lewis wrote:
Fahd Mirza wrote:
Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
That may depend on the software you use to load the data, it's not a necessity from the perspective of the database.I am using Oracle Warehouse Builder to load the data into the database.
>
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
Depends on the tools, and whether there is data in the table already - but Oracle will optimise index maintenance for bulk inserts in a way which means that it isn't necessary to worry about dropping/recreating if the index already exists and the table is empty.There is no data in the partitions prior to loading.
You may find that with one index it's more efficient to create the index with a lot of free space (51%, say) and leave it at that while another index works better if you mark unusable and rebuild.
Would you please elaborate on this point?
>
>>
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Your question raise more questions:
a) Does this mean you are only going to have a maximum of two bitmap indexes on this fact table with 60 million rows ? That doesn't sound like it's enough indexes.No, I will create local bitmap indexes on other columns too, which are likely to be used in the adhoc queries.
b) Are you hoping that the vactivity bitmap index will protect you against foreign key locking ? It won't. This (in part) is why people tend to set FK's to disable, novalidate, rely in data warehouses, they want bitmap indexes not btree indexesActually I haven't created the FK constraint.
d) Going back to the bitmap index on the date - is this column storing values that are date-only, or is it storing "date with time". If it's date-only then you've only got one date per partition and the index is a waste of space and processing overhead.The datatype of the column vdate is number. Actually it is refering to the pk of time dimension, in which we have preloaded the dates for the next ten years. Would the index be a total waste on this column?
>
>
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Here is the table. I have omitted many partitions for the sake of brevity:
CREATE TABLE CDR
CLNG_NMBR          NUMBER,
   CL_RFRNC_NMBR      VARCHAR2(100 BYTE),
DT_KY              NUMBER,
TM_KY              NUMBER,
HRLY_KY            NUMBER,
ACTVTY_KY          NUMBER,
INS_DT             DATE,
SRVC_ID            VARCHAR2(100 BYTE),
MSC_ADRS           VARCHAR2(100 BYTE),
TRF_ID             NUMBER,
CL_TYP             NUMBER,
LCTN_INFRMTN       VARCHAR2(100 BYTE),
LCTN_KY            NUMBER,
SRC_CLNG_NMBR      VARCHAR2(50 BYTE),
ACTVTY_CL_TP       VARCHAR2(100 CHAR)
PARTITION BY RANGE(DT_KY)
PARTITION DAY_20DEC2009 VALUES LESS THAN (4153),
PARTITION DAY_21DEC2009 VALUES LESS THAN (4154),
PARTITION DAY_22DEC2009 VALUES LESS THAN (4155),
PARTITION DAY_23DEC2009 VALUES LESS THAN (4156),
PARTITION DAY_24DEC2009 VALUES LESS THAN (4157),
PARTITION DAY_25DEC2009 VALUES LESS THAN (4158),
PARTITION DAY_26DEC2009 VALUES LESS THAN (4159),
PARTITION DAY_27DEC2009 VALUES LESS THAN (4160),
PARTITION DAY_28DEC2009 VALUES LESS THAN (4161),
PARTITION DAY_31DEC2011 VALUES LESS THAN (4894),
PARTITION DAY_END_PART VALUES LESS THAN (MAXVALUE)
TABLESPACE cdr
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          80K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;Many many thanks and best regards
Fahd
Edited by: Fahd Mirza on Jun 3, 2010 2:00 PM
Edited by: Fahd Mirza on Jun 3, 2010 2:03 PM

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 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/

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

How to make use of package "com.sapportals.wcm.repository"

Dear all,
I am trying to make use the package "com.sapportals.wcm.repository" in my SDK development. But when I entered "import com.sapportals.wcm.repository.*;" in my class, a error given out "The import com.sapportals.wcm cannot be resolved.". What should I do?
Thanks
Sam

Hi Armin,
Sorry that I still got problem on importing and make use of the class for knowledgemanagement. I can found the cooresponding .jar file in folder "jakarta-tomcat-3.3.2\webapps\irj\WEB-INF\plugins\portal\services\knowledgemanagement\lib". And added the services reference as "ServicesReference=htmlb, knowledgemanagement". However, I still can't use the class for KM.
I have read those code sample from KM in SDN, but they are mentioning the programming part and not the setting. Can you suggest the detail steps and code on adding the KM class into my customize class?
I am using Eclipse as my development tools.
Thanks & Regards
Sam
Message was edited by: Sam Choy

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

Trying to make use of bitmap indexes

Similar Messages

Maybe you are looking for