Bitmap Index Question

I have a star schema database setup with a bunch of definition tables with 2-10 values in each. Most things I read say to use bitmap only in data warehousing, but in the same breath talk about tables exactly like I have them set up. So my question is, do bitmap indexes ever have a use outside of data warehouse? We don't do millions of transactions on hr, but it is an asset management front end run using php. So the main data tables is getting updated, inserted, and deleted during the day. I'd say on average we have about 30 users at any given time performing actions on the tables or pulling reports.
On side note, but still related to indexes, is it better to have the indexes stored in different tablespace from the tables? If so, what is its effect?
Thanks in advance.
Setup:
Oracle 11g running on Ubuntu 9.10 64bit

ChaosAD wrote:
I have a star schema database setup with a bunch of definition tables with 2-10 values in each. Most things I read say to use bitmap only in data warehousing, but in the same breath talk about tables exactly like I have them set up. So my question is, do bitmap indexes ever have a use outside of data warehouse? We don't do millions of transactions on hr, but it is an asset management front end run using php. So the main data tables is getting updated, inserted, and deleted during the day. I'd say on average we have about 30 users at any given time performing actions on the tables or pulling reports.
Having STAR schema design for a transactional processing application seems bit strange (but what do I know...).
Have you verified/validated that you definitely need bitmap indexes and B*Tree indexes will not serve the purpose? Just because it is a STAR schema does not necessarily mean one has to have bitmap indexes.
If you expect 30 users (on average) to concurrently modify the data, I believe bitmap indexes is not the right choice as the DML actions will suffer from contention. Bitmap indexes negatively affect the concurrent multiple transactions.
Rafi has answered your second question.

Similar Messages

Multi-column BITMAP index vs. multiple BITMAP indices?

Given the table (simple, made-up example):
CREATE TABLE applicant_diversity_info (
applicant_diversity_id NUMBER(12), PRIMARY KEY(applicant_diversity_id),
apply_date DATE,
ssn_salted_md5 RAW(16),
gender CHAR(1), CHECK ( (gender IS NULL OR gender IN ('M','F')) ),
racial_continent VARCHAR2(30), CHECK ( (racial_continent IS NULL
OR racial_continent IN ('Europe','Africa','America','Asia_Pacific')) ),
ethnic_supergroup VARCHAR2(30), CHECK ( (ethnic_supergroup IS NULL OR ethnic_supergroup IN ('Latin American','Other')) ),
hire_salary NUMBER(11,2),
hire_month DATE,
termination_salary NUMBER(11,2),
termination_month DATE,
termination_cause VARCHAR2(30), CHECK ( (termination_cause IS NULL
OR termination_cause IN ('Resigned','Leave of Absence','Laid Off','Performance','Cause')) )
Oracle (syntactically) allows me to create either one BITMAP index over all four small-cardinality columns
CREATE BITMAP INDEX applicant_diversity_diversity_idx ON applicant_diversity_info (
gender, racial_continent, ethnic_supergroup, termination_reason );
or four independent indexes
CREATE BITMAP INDEX applicant_diversity_gender_idx ON applicant_diversity_info ( gender );
CREATE BITMAP INDEX applicant_diversity_race_idx ON applicant_diversity_info ( raceial_continent );
etc.
What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
And, if I define one multi-column BITMAP index, does the order of columns matter?

>
What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
And, if I define one multi-column BITMAP index, does the order of columns matter?
>
You may want to read this two-part blog, that answers that exact question, by recognized expert Richard Foote
http://richardfoote.wordpress.com/2010/05/06/concatenated-bitmap-indexes-part-i-two-of-us/
http://richardfoote.wordpress.com/2010/05/12/concatenated-bitmap-indexes-part-ii-everybodys-got-to-learn-sometime/
As with many things Oracle the answer is 'it depends'.
In short the same considerations apply for a concatenated index whether it is bitmap or b-tree: 1) will the leading column usually be in the predicate and 2) will most or all of the index columns be specified in the queries.
Here are some quotes from part 1
>
Many of the same issues and factors in deciding to create a single, multi-column index vs. several, single column indexes apply to Bitmap indexes as they do with B-Tree indexes, although there are a number of key differences to consider as well.
Another thing to note regarding a concatenated Bitmap index is that the potential number of index entries is a product of distinct combinations of data of the indexed columns.
A concatenated Bitmap index can potentially use less or more space than corresponding single column indexes, it depends on the number of index entries that are derived and the distribution of the data with the table.
>
Here is the lead quote from part 2
>
The issues regarding whether to go for single column indexes vs. concatenated indexes are similar for Bitmap indexes as they are for B-Tree indexes.
It’s generally more efficient to access a concatenated index as it’s only the one index with less processing and less throwaway rowids/rows to contend with. However it’s more flexible to have single column indexes, especially for Bitmap indexes that are kinda designed to be used concurrently, as concatenated indexes are heavily dependant on the leading column being known in queries.

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

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

Bitmap index or Composite index better on a huge table

Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.
Regars,
Madhu K.

Dear,
Hi All,
I got a question regarding the Bitmap index and Composite Index.
I got a table which has got only two colums CUSTOMER(group_no NUMBER, order_no NUMBER)
This is a 100Million+ record table and here I got 100K Group_nos and and unique 100Million order numbers. I.E Each group should have 1000 order numbers.
I tested by creating a GLOBAL Bitmap index on this huge table(more than 1.5gb in size) and the GLOBAL Bitmap index that got created is under 50MB and when I query for a group number say SELECT * FROM CUSTOMER WHERE group_no=67677; --> 0.5 seconds to retrive all the 1000 rows. I checked for different groups and it is the same.
Now I dropped the BitMap Index and re-created a Composite index on( group_no and order_no). The index size more than the table size and is around 2GB in size and when I query using the same select statment SELECT * FROM CUSTOMER WHERE group_no=67677; -->0.5 seconds to retrive all the 1000 rows.
My question is which one is BETTER. BTree or BITMAP Index and WHY?
Appreciate your valuable inputs on this one.First of all, bitmap indexes are not recommended for write intensive OLTP applications due to the locking threat they can produce in such a kind of applications.
You told us that this table is never updated; I suppose it is not deleted also.
Second, bitmap indexes are suitable for columns having low cardinality. The question is how can we define "low cardinality", you said that you have 100,000 distincts group_no on a table of 100,000,000 rows.
You have a cardinality of 100,000/100,000,000 =0,001. Group_no column might be a good candidate for a bitmap index.
You said that order_no is unique so you have a very high cardinality on this column and it might not be a candidate for your bitmap index
Third, your query where clause involves only the group_no column so why are you including both columns when testing the bitmap and the b-tree index?
Are you designing such a kind of index in order to not visit the table? but in your case the table is made only of those two columns, so why not follow Hermant advise for an Index Organized Table?
Finally, you can have more details about bitmap indexes in the following richard foot blog article
http://richardfoote.wordpress.com/2008/02/01/bitmap-indexes-with-many-distinct-column-values-wotsuh-the-deal/
Best Regards
Mohamed Houri

Bitmap indexes

hi everyone,
There is table t
and there are several bitmap one-column indexes
i1 on t(c1)
i2 on t(c2)
i3 on t(c3)
Column C1 is not nullable.
Columns C2 and C3 is nullable.
There is query
select /*+ index_combine(t) */
from t
where c1 = :1
   and c2 in (:2, 'X')
   and c3 = :3
| Id | Operation                     |
|   0 | SELECT STATEMENT              |
|   1 | TABLE ACCESS BY INDEX ROWID |
|   2 |   BITMAP CONVERSION TO ROWIDS |
|   3 |    BITMAP AND                 |
|   4 |     BITMAP INDEX SINGLE VALUE |
|   5 |     BITMAP INDEX SINGLE VALUE |
|   6 |     BITMAP OR                 |
|   7 |      BITMAP INDEX SINGLE VALUE|
|   8 |      BITMAP INDEX SINGLE VALUE|
---------------------------------------Fine.
But if I create following indexes (and drop previous)
create bitmap index idx1 on t(C1, C2);
create bitmap index idx2 on t(C1, C3);
then the plan of the query above is following:
| Id | Operation                    |
|   0 | SELECT STATEMENT             |
|   1 | TABLE ACCESS BY INDEX ROWID |
|   2 |   BITMAP CONVERSION TO ROWIDS|
|   3 |    BITMAP INDEX SINGLE VALUE |
--------------------------------------And the question:
why the plan does not consist BITMAP AND ?
Is it possible to scan both new indexes in the query with BITMAP AND?
Thanks

793769 wrote:
Jonathan Lewis wrote:
I think this means there's a hole in the optimizer's legal strategies that you might have to fill by other methods.Do I right understand that it is impossible to combine bitmap non-one-column indexes?No, you're generalising from the particular - thus are myths created.
I have demonstrated a case where two bitmap indexes start with the same column+, and the optimizer therefore refuses to do a "bitmap and" between these two indexes when you have where clause that uses equality on the common first column and equalities on the seperate second columns. This is a very small subset of query patterns involving combinations of "non-one-column" (multi-column) indexes.
For example - why don't you try recreating your (c1, c3) index as (c3, c1) to see what the optimizer can do ?
In my example it produced the following path:
| Id | Operation                    | Name    | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT             |         |    10 | 1250 |     6 |
|   1 | TABLE ACCESS BY INDEX ROWID | T1      |    10 | 1250 |     6 |
|   2 |   BITMAP CONVERSION TO ROWIDS|         |       |       |       |
|   3 |    BITMAP AND                |         |       |       |       |
|* 4 |     BITMAP INDEX SINGLE VALUE| T1_B1B2 |       |       |       |
|   5 |     BITMAP MERGE             |         |       |       |       |
|* 6 |      BITMAP INDEX RANGE SCAN | T1_B3B1 |       |       |       |
Predicate Information (identified by operation id):
   4 - access("C1"=5 AND "C2"=50)
   6 - access("C3"=50)
       filter("C3"=50)So it is combining two multi column indexes - but it doesn't appear to be able to use the common column twice to make the second index access as efficient as possible. (This plan appeared for 10.2.0.3 and 11.2.0.2).
Regards
Jonathan Lewis

BW, BRTools, statistics, monitoring and bitmap indexes.

Hi all, I have a question about the above.
Oracle 10.2, Solaris 10, BW 7.00
We have a script that generates statistics weekly on our systems. lately, I have been noticing the following messages in the output after the BRTools statistics job is run:
BR0988W Bitmap index "Index_name" selected for checking statistics - please activate the monitoring attribute for table "Table_name"***
After reading SAPNotes 442395, 588688 & 408527, doing searches of SAPNotes, this forum and other forums such as ITToolbox, the answer to the above is "activate monitoring for the above/all tables". I get this.
My issue is that after seeing warnings or missing/skipped statistics, I will manually run the following
brconnect -u / -c -f stats -t all -p 4 as the SID_ORA user
When I do that, the warning message (BR0988W) does not appear in the output. And if I check the table in Oracle with something like the following:
select tablespace_name, table_name, partitioned, monitoring from all_tables where table_name = '"Table_name"';
The ouput is
TABLESPACE_NAME TABLE_NAME PAR MON
"Tablespace_name" "Table_name" YES YES
which shows that monitoring is activated for the table.
My question is, by running "brconnect -u / -c -f stats -t all -p 4" was monitoring turned on? This would mean that I would not have to run the script suggested in 408527. Or can the BR0988W error be generated even though monitoring is activated.
The next time I see the error in the statistics output, I will run the SQL and check the status of the table before running the BRTools stats update.
Table_name and Index_name are just generic markers. I have checked and confirmed that I have not mistyped actual names when running select statements.

As far as i know this message is outdated with 10g.
Please have a look at this discussion: DB13 - Update Sttats - activate the monitoring attribute for table
Cheers Michael

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

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

DB 13 Message logs BR0988W Bitmap index /BI0/F0COPC_C08~08 selected for che

Dear Exprts,
We are getting following error in DB13 check DB, our server is BW Test and version BW3.5.
Kindly Suggest.
BR0988W Bitmap index /BI0/F0COPC_C08~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0CO
BR0988W Bitmap index /BI0/F0LSO_C01~020 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0LS
BR0988W Bitmap index /BI0/F0LSO_C02~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0LS
BR0988W Bitmap index /BI0/F0PAPA_C02~11 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PA
BR0988W Bitmap index /BI0/F0PE_C01~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BI0/F0PE_C02~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BI0/F0PE_C03~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BIC/FC_0IC_C03~11 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_0
BR0988W Bitmap index /BIC/FC_0SD_C03~12 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_0
BR0988W Bitmap index /BIC/FC_AS_ROM~060 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_A
BR0988W Bitmap index /BIC/FC_BOL_BU~900 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_BOL_DBL~07 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_BOL_RTL~07 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_CUST_MA~04 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_C
BR0988W Bitmap index /BIC/FC_FRSRCP~110 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_F
BR0988W Bitmap index /BIC/FC_HITMISL~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_H
BR0988W Bitmap index /BIC/FC_HITMISS~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_H
BR0988W Bitmap index /BIC/FC_MRL_RTL~06 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_M
Regards
Yogesh

Hi,
check SAP Note Note 442395 - Descriptions of specific BR messages
search for BR0988W in note.
then Activate the MONITORING attribute for the table in question as per note.
also check Note 408527 - Checking the statistics using DBA_TAB_MODIFICATIONS
regards,
kaushal

Bitmap Indexes in 10G

Hi all,
Seems like a pretty basic question but have not been able to find a conclusive answer looking around. I know that bitmap indexes only worked on oracle 9i Enterprise edition - is the same through with 10G or can they be used on standard/standard one also?
Many thanks

Seems like a pretty basic question but have not been
able to find a conclusive answer looking around. IGet the answer from Oracle:
- Go to http://www.oracle.com/pls/db102/homepage
- Select Licensing Information (bottom, first column)
- Select Chapter 1 - Oracle Dtaabase Editions
- Search for Bitmap
(Surprising what it in the documentation. <g>)

How BITMAP INDEX SINGLE VALUE returns rows ?

Hi guys,
here is piece from serial execution plan (display_cursor)
| Id | Operation                                        | Name                         | Starts | E-Rows | A-Rows |
| 48 |                  PARTITION LIST ALL              |                              |   3712 |        |   4089K|
| 49 |                   BITMAP CONVERSION TO ROWIDS    |                              | 40832 |        |   4089K|
| 50 |                    BITMAP AND                    |                              | 40832 |        | 23708 |
|* 51 |                     BITMAP INDEX SINGLE VALUE    | IDX1                         | 40832 |        | 26014 |
|* 52 |                     BITMAP INDEX SINGLE VALUE    | IDX2                         | 40832 |        | 28076 |
...What does mean such difference in A-Rows in steps 50->49, from 23708 to 4089K.
Do steps 51-52 return not regular rows but rows with bitmaps, which consist many regular rows?

853118 wrote:
here is piece from serial execution plan (display_cursor)
What does mean such difference in A-Rows in steps 50->49, from 23708 to 4089K.
Do steps 51-52 return not regular rows but rows with bitmaps, which consist many regular rows?First of all have you noticed that you have more than 40,000 starts of these operations accounted for? That explains why you see more than 1 "row" accounted for the "single value" operation. But to answer your question: Yes, a single value in a bitmap index will have one or more bitmap pieces, and each bitmap piece covers a range of ROWIDs with the bitmap (0 or 1) pattern that tells whether the value is stored in that row or not.
So a single value of a bitmap can potentially return many, if not all rows of a table. The "rows" output in the A-Rows column for bitmap indexes is probably the number of bitmap pieces (sometimes also called "fragments" I think) and therefore can look pretty small in comparison to the rows actually accessed in the table based on the information extracted from those bitmap pieces.
For more info, I recommend to have a look at Julian Dyke's presentation about bitmap index internals: http://www.juliandyke.com/Presentations/BitmapIndexInternals.ppt
Also Greg Rahn has an interesting blog post that also covers the discrepancy between "rows" of a bitmap operation and "rows" of the corresponding table access: http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/
Hope that helps,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
Co-author of the "OakTable Expert Oracle Practices" book:
http://www.apress.com/book/view/1430226684
http://www.amazon.com/Expert-Oracle-Practices-Database-Administration/dp/1430226684

IMPLEMENTATION OF BITMAP INDEXING

I have a question regarding implementation of BitMap Indexing.
While using BitMap Indexing over a low cardinality column in a table having huge records (say 5 Million), what would be the approaches to reach to the record in the table that are stored in the file.
For example supoose in a query we have a condition
"gender = 'M'"
Now if we apply BitMap Index over column "Gender" and select couple of records through masking Can anybody suggest a better approach so that corresponding records can be selected.
Wait for an intelligent reply from Masters.
Thanks.

Guessing...
You 'index' the data and create 'groups' which already match each bit.
Obviously this can get complicated when the data changes. You either have to re-index at some time. You can do it immediately, or you can do it at some other interval. The first is an obvious performance problem. The second requires that you keep an un-indexed cache.

Help required in Index Question

Hi,
This is an interview question that i faced.
Theres a table Statistics having more than 300 columns. It has normal indexes on say five columns col1, col2, col3, col4, col5.
Queries involving the first four columns give excellent performance but the query involving col5 gives poor performance.
COL5 has around 5 million data and 1 normal index ix created on it and theres just one value in it say 'STATS'.(He said the query can be simple select queries or join queries, the queries may select all the rows of few rows may be 5%, 10% etc).
The question was what could be the possible reason?
I was unable to answer it but i think BITMAP index might be useful in this scenario.
Any help or suggestions will be highly appreciated.

Is it a good idea to creat a normal index on a column that have just one value as 'STATS' and the total no of rows is more than 5 million??
No
See the I/O
SQL> CREATE TABLE bitmap_table AS SELECT ROWNUM rn FROM all_objects
2 /
Table created.
SQL> ALTER TABLE bitmap_table ADD (status VARCHAR2(1))
2 /
Table altered.
SQL> SELECT COUNT(*) FROM bitmap_table
2 /
COUNT(*)
    64177
SQL> UPDATE bitmap_table SET status='Y'
2 /
64177 rows updated.
SQL> COMMIT
2 /
Commit complete.
SQL> CREATE TABLE btree_table AS SELECT * FROM bitmap_table
2 /
Table created.
SQL> CREATE BITMAP INDEX bitmap_table_idx ON bitmap_table (status)
2 /
Index created.
SQL> CREATE INDEX btree_table_idx ON btree_table (status)
2 /
Index created.
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT','BITMAP_TABLE')
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_STATS.GATHER_INDEX_STATS('SCOTT','BITMAP_TABLE_IDX')
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT','BTREE_TABLE')
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_STATS.GATHER_INDEX_STATS('SCOTT','BTREE_TABLE_IDX')
PL/SQL procedure successfully completed.
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT status
2    FROM bitmap_table
3   WHERE status='Y'
4 /
64177 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=64177 Bytes
          =128354)
   1    0   BITMAP CONVERSION (TO ROWIDS) (Cost=2 Card=64177 Bytes=128
          354)
   2    1     BITMAP INDEX (FAST FULL SCAN) OF 'BITMAP_TABLE_IDX' (IND
          EX (BITMAP))
Statistics
        171 recursive calls
          0 db block gets
         31 consistent gets
          0 physical reads
          0 redo size
     804546 bytes sent via SQL*Net to client
     475281 bytes received via SQL*Net from client
       4280 SQL*Net roundtrips to/from client
          4 sorts (memory)
          0 sorts (disk)
      64177 rows processed
SQL> DROP INDEX BITMAP_TABLE_IDX
2 /
Index dropped.
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT','BITMAP_TABLE')
PL/SQL procedure successfully completed.
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT status
2    FROM bitmap_table
3   WHERE status='Y'
4 /
64177 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=26 Card=64202 Byte
          s=128404)
   1    0   TABLE ACCESS (FULL) OF 'BITMAP_TABLE' (TABLE) (Cost=26 Car
          d=64202 Bytes=128404)
Statistics
        192 recursive calls
          0 db block gets
       4405 consistent gets
          0 physical reads
          0 redo size
     804546 bytes sent via SQL*Net to client
     475281 bytes received via SQL*Net from client
       4280 SQL*Net roundtrips to/from client
          4 sorts (memory)
          0 sorts (disk)
      64177 rows processed
SQL> SELECT status
2    FROM btree_table
3   WHERE status='Y'
4 /
64177 rows selected.
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=27 Card=64177 Byte
          s=128354)
   1    0   INDEX (FAST FULL SCAN) OF 'BTREE_TABLE_IDX' (INDEX) (Cost=
          27 Card=64177 Bytes=128354)
Statistics
        171 recursive calls
          0 db block gets
       4429 consistent gets
          0 physical reads
          0 redo size
     804546 bytes sent via SQL*Net to client
     475281 bytes received via SQL*Net from client
       4280 SQL*Net roundtrips to/from client
          4 sorts (memory)
          0 sorts (disk)
      64177 rows processed
SQL> SELECT index_name,blevel,num_rows
2    FROM user_indexes
3   WHERE index_name='BTREE_TABLE_IDX'
4 /
INDEX_NAME                        BLEVEL NUM_ROWS
BTREE_TABLE_IDX                        1     64177
SQL> SELECT index_name,blevel,num_rows
2    FROM user_indexes
3* WHERE index_name='BITMAP_TABLE_IDX'
SQL> /
INDEX_NAME                        BLEVEL NUM_ROWS
BITMAP_TABLE_IDX                       1         3Khurram

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 Question

Similar Messages

Maybe you are looking for