Diff b/w btree and bitmap index ?

What is the difference between btree and bitmap index ?
which one to used and when.
how they are differ from each other.

you'd love to see
http://www.oracle.com/technology/pub/articles/sharma_indexes.html

Similar Messages

Which index I should create Btree or Bitmap index?

I have table with columns c1,c2,c3
I want to create index on column c1
which index I should create Btree or Bitmap index
the column contain 50% unique values and 50% duplicate values
If Btree why?
If Bitmap Why?
I know that
Btree is used when there more unique values (high cardinality)
Bitmap is used when there less unique values (low cardinality)

read this -
Deadlocks with Bitmap Indexes
Bitmap indexes were designed to be used solely within data warehouses, i.e. where the vast majority of the database activity is reading data,
and there's very little (or no) data modification, except for batch processes which occasionally re-populate the warehouse.
Each "row" in the bitmap index contains references to potentially many different rowids, in contrast to a B*-tree index which references a single rowid.
It should be obvious, therefore, that, since the transactional mechanism is the same for all database operations, that any DML on a table which impacts the bitmap index may end up locking (or attempting to lock) many different "rows" within the index.
This is the key concept with deadlocks in bitmap indexes, you're not being deadlocked on the underlying table, but on the index blocks. Courtesy - http://www.oratechinfo.co.uk/deadlocks.html
hope u got it now...

Refreshing Materialized View and (Bitmap) indexes

In my data warehouse I have an MV that is re-built every night.
1. Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule
2. It was sometimes sensitive to changes in the underlying objects
3. Its has union alls in it so is complex
It has 6 indexes (4 bitmap and 2 b-tree) built on it which take between 8 and 20 minutes each to create. I would like to reduce this time. I'm already doing the index creation as parallel jobs.
I can re-organise the underlying tables so that the MV is no longer complex, and put an MV log on, to enable a fast refresh. Then, ideally, the indexes can be permanent But I know that bitmap indexes don't like certain changes (they can multiply in size an become unusable). Does this include refreshes of MVs? If it does I might be able to switch to b-tree indexes as our report performance is well within the allowable window, unlike my nightly ETL.
The MV has 160M rows in it and the rate of change is rarely more than 1%/day
I'm on 9i

<Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule >
Huh? I wouldn't think that a drop and recreate would be any faster, but won't argue with your results. I assume the same events happen for both and take the same amount of time, with the drop/refresh promoting fragmentation.
< It was sometimes sensitive to changes in the underlying objects >
Yup. All kinds of views are, even real ones. I've found that on 10g MVs are also very tempermental
< Simplest answer from me is that I will go for a fast refresh with MV logs. >
I'm not sure you can fast refresh a query with UNIONS. There's a list of restrictions for fast refreshes that's so long I can't keep track of all the rules.
< would you drop and recreate the bitmp indexes either side of the fast refresh? >
If you're doing a fast refresh you shoud not need to.
You might also consider using the NOLOGGING option on index dropping recreation, used to turn archivel logging off. Since you won't be restoring a failed index creation in case of database failure anyway it should be fairly safe.
Also, when creating the bitmaps make sure you're allocating enough memory to the process. Check your initialization/session parameters, particularly the ones pertianing to bitmap indexes.
Message was edited by:
riedelme

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

Difference between btree index and bitmap index

i knw btree is the default index.but what's are the other difference present.

21 characters and 10 seconds at google:
http://www.akadia.com/services/ora_bitmapped_index.html
http://www.oracle.com/technology/pub/articles/sharma_indexes.html
http://www.dba-oracle.com/art_9i_indexing.htm
Dim

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 index and BLEVEL

Hi All,
We have one BITMAP index on a flag column (Y/N).Table is non partitioned with 3.4 million records.
Following are index stats.
select INDEX_NAME,INDEX_TYPE,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,CLUSTERING_FACTOR,NUM_ROWS,SAMPLE_SIZE,DEGREE FROM DBA_INDEXES WHERE
INDEX_NAME='LATE_VER_FLG_CAX_IDX' AND OWNER='EQHUB'
INDEX_NAME           INDEX_TYPE     BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS SAMPLE_SIZE DEGREE
LATE_VER_FLG_CAX_IDX BITMAP             11         716             2             72783      72783       72783 1
select last_analyzed,sample_size,num_rows from dba_indexes where index_name='LATE_VER_FLG_CAX_IDX';
LAST_ANALYZED      SAMPLE_SIZE   NUM_ROWS
31.Jan.09/00:29:41       72783      72783
NAME                      HEIGHT     BLOCKS    LF_ROWS    LF_BLKS LF_ROWS_LEN    BR_ROWS    BR_BLKS DEL_LF_ROWS DISTINCT_KEYS BTREE_SPACE USED_SPACE   PCT_USED
LATE_VER_FLG_CAX_IDX          12       4352          0          0                      1          1           0             0        8028
CREATE BITMAP INDEX "EQHUB"."LATE_VER_FLG_CAX_IDX" ON "EQHUB"."BBO_CORPORATE_ACTIONS" ("LATEST_VERSION_FLAG")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 2097152 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "ETDHUB_EQHUB_INDEX"
SQL> select LATEST_VERSION_FLAG,count(*) from BBO_CORPORATE_ACTIONS group by LATEST_VERSION_FLAG;
L   COUNT(*)
N    2265303
Y    1189116I am wondering
1.What can be done to reduce index BLEVEL/HEIGHT? (i assume COALESCE will not help)..Should i rebuild the index?
2.Why BTREE_SPACE is only showing 8028 where dba_segments is showing index size =34 MB?
3.Why PCT_USED is NULL?
Is that so BLEVEL/PCT_USED not relative for BITMAP Indexes?
I found that no query is using this index for last 60 days and performance is getting degraded due to FTS.
Should i REBUILD the index so that i can reduce BLEVEL/HEIGHT/INDEX_SIZE and improve query performance with INDEX ACCESS.
Regards,
Bhavik Desai

Bhavik Desai wrote:
You perfectely caught the DML pattern.There are 4 daily ELT jobs which INSERT 300 and UPDATE 250 records/execution.
May i ask you,upon which observation,you point this?Also it would be greate if you tell me how did you calculate 67% PCT_FREE.
This was based on the fact that an update to a single row in a table could result in a copy of an entire bitmap index chunk being made; so you need to leave a lot of space free in the leaf blocks to allow for these copies because you really don't want to cause an index leaf block split to occur - especially since that would tend to cascade up the index and cause a branch block split as well. On this basis, pctfree 51 should be adequate for most cases, but setting it to 67 (a) allows you to do a couple of updates/clones to the same chunk before you hit a problem, and (b) helps to keep the chunks smaller which helps to reduce the undo and redo a bit.
This has just reminded me of a little detail - I am a little surprised by the fact that you got an index into this state in 10.2, because that release of Oracle seems to avoid creating a long chain of clones of the same index chunk when you do a series of small updates, and it is the chain of clones that results in branch blocks split running up the index and exploding it to an enormous height. Has this database been upgraded from 9i (or even 10.1) some time in the fairly recent past ?
>
I still dont understand,
1.Why there is no difference in BTREE_SPACE?
2.Why PCT_USED is NULL?
I've just run a quick test on 10.2.0.1 and 10.2.0.3 creating a table with a y/n/null column and creating a bitmap index on it. The results from index_stats didn't match across versions, and the 10.2.0.3 stats were clearly garbage - very similar to yours. For the moment I would assume that something has been broken in 10.2.0.3 with this use of the validate command.
>
If we consider Franck Pachot's observation,then it would be better to convert the BITMAP to BTREE.Is this a normal bitmap behavior?Randolf's observation about the numbers of rows involved is most relevant: it doesn't look like an index that the optimizer should consider using for anything other than select flag, count(*), and changing from a bitmap to a btree won't make any difference. In other words, unless you can point to an important piece of code and say "it makes tis bit run much better" maybe the index shouldn't exist at all.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The temptation to form premature theories upon insufficient data is the bane of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear".

Bitmap index and group by queries

Please could someone offer me some advice for a data warehouse table I am designing which will have ad hoc queries running against it mainly grouping by day/month/year and needs to use as little resources as possible.
TRANS_DATE DATE, LOC_ID VARCHAR2(8), USER_ID VARCHAR2(8), TRANS_CODE VARCHAR2(3), COUNT NUMBER(8,0)
In populating the table I truncated the trans_date to hourly data and aggregated the other columns to give me an hourly count for every combination of location, user and code. I wasn't sure if I should create 2 more columns with truncated dates by day and by month? There are 200,000 rows per day in this table.
The first 4 columns have low cardinality so I decided to create Bitmap indexes on them. However, when querying in Application Express SQL Workshop and looking at the query plan it seems that a full table scan is being performed whenever I use a group_by(example below), even when i use a hint for the index. The bitmap index is used on simple select queries with where clauses but no grouping.
SELECT LOC_ID, count(TOTAL)
FROM TRANS_SUMMARY
GROUP BY LOC_ID
Am I doing this the right way? Or would multiple materialised views / btree indexes be a better way of ensuring fast group_by queries on this table?
Thanks in advance.
Paul

You don't need a separate materialized view for every combination. You may need a few carefully chosen combinations, in addition to appropriate dimensions for rollups.
For example, a materialized view that aggregated dat based on location_id, trans_code, and hour could be used to aggregate by location_id, trans_code and day (i.e. adding up 24 rows from the MV for each trans_code and location_id) or location_id, trans_code and month (i.e. adding 24*30 rows from the MV for each trans_code and location_id). The more rows you have to aggregate, and the more frequently the higher level aggregates are accessed, the more likely you'd want to have a separate MV that aggregates at the higher level (i.e. if you're accessing monthly summary data totals all the time).
If you are rarely aggregating by trans_code, and you have lots of different trans_code values, you could use the one MV that aggregated by location_id, trans_code, and hour to do a monthly aggregate just on location_id and month, but that requires adding 24*30*# trans_code rows from the MV, which may be expensive. It may make sense to have a separate MV for that, or a set of MV's that are aggregated just by location_id and day, or some combination.
Justin

Does dropping bitmap index and creation of b- index cause any dead locks

Does dropping a bitmap index on table which is being used continuously for DML operations and creation of b- index cause any dead locks on a table
in oracle 10g database
( 10.1.0.4.0 - 64bi).
we have seen alert log file which has dead lock occurrence.. would index change/re-creation resulted dead lock or some other reason?
Could you please give us info or help us on this.. thanks in advance..

Bitmap indexes can be the cause of deadlocks on busy systems.
Dropping indexes may cause some locking.
Creating indexes may cause some locking.
You haven't given any traces or scripts or lock information, so difficult to say which one (if any) was the cause of your deadlocks.
It would be better to do this activity when the system is not busy.

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

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

Bitmap indexes have effect on query execution and equation of values.

Hi,
I have a Fact table and 17 dimension tables linked to it. On each foreign-key in the Fact-Table I have created a BITMAP Index. After that I Analyzed the fact table and made sure that the referential constraints were valid.
Everything seem to be OK until I ran into a difference in totals when using the next 2 queries that should both result into the same total amount.
Query 1:
Below query is resulting in a wrong total amount and seems to be cartesian.
SELECT    SUM(F.DOLLARS)
FROM       SALES_FACTS         F
,               DIM_TIME                A
,               DIM_CUSTOMER      B
,               DIM_SALESAGENT C
,               DIM_SALESTYPE     D
,               DIM_GEOGRAFIC     E
WHERE    F.TIME_ID     =     A.TIME_ID
AND         F.CUST_ID     =    B.CUST_ID
AND         F.SA_ID         =    C.SA_ID
AND         F.ST_ID          =   D.ST_ID
AND         F.GEO_ID       =   E.GEO_ID
AND         A.YEAR          =   '2006'
AND         C.SALESNUM =   '3770'
AND D.ST_ID <> '4'
Query 2:
Qeury 2 is the same as query 1 exept the the type of sales (D.ST_ID) is now set with in a range of allowed values. This query gives the correct result.
SELECT    SUM(F.DOLLARS)
FROM       SALES_FACTS         F
,               DIM_TIME                A
,               DIM_CUSTOMER      B
,               DIM_SALESAGENT C
,               DIM_SALESTYPE     D
,               DIM_GEOGRAFIC     E
WHERE    F.TIME_ID     =     A.TIME_ID
AND         F.CUST_ID     =    B.CUST_ID
AND         F.SA_ID         =    C.SA_ID
AND         F.ST_ID          =   D.ST_ID
AND         F.GEO_ID       =   E.GEO_ID
AND         A.YEAR          =   '2006'
AND         C.SALESNUM =   '3770'
AND D.ST_ID in ('1','2','3','5') In my situation it seems that when I use the <> (not equal to) symbols in combination with the bitmap indexes, that the result of the sum becomes cartesian and thus incorrect.
Has anyone an idea why the calculation of the total amount is different in both queries?
Any help is very appreciated.
Regards, Ilona

Another strange effect is when I leave out the quotation around the not equal to 4 for the Sales_type id (ST_ID <> 4 in stead op ST_ID <> '4' ) then the totals is perfect.
Query 1 version without quotations around ST_ID:
SELECT    SUM(F.DOLLARS)
FROM       SALES_FACTS         F
,               DIM_TIME                A
,               DIM_CUSTOMER      B
,               DIM_SALESAGENT C
,               DIM_SALESTYPE     D
,               DIM_GEOGRAFIC     E
WHERE    F.TIME_ID     =     A.TIME_ID
AND         F.CUST_ID     =    B.CUST_ID
AND         F.SA_ID         =    C.SA_ID
AND         F.ST_ID          =   D.ST_ID
AND         F.GEO_ID       =   E.GEO_ID
AND         A.YEAR          =   '2006'
AND         C.SALESNUM =   '3770'
AND D.ST_ID <> 4 I still have no clue what causes this effect.
Regards, Ilona

ABAP-- diff between sy-sy-tabix and sy-index

Hi Guru's,
Pleae can anybody expalins me what is the difference between sy-tabix and sy-index(Loop Index) ?
Because in one case i am Modifyimg the internal table inside the do loop by giving sy-index ((Index of Internal Tables)(MODIFY scarr_tab INDEX sy-index FROM scarr_wa TRANSPORTING currcode. ) in the syntax and in other case inside loop statement i am modifyng same record by giving sy-tabix MODIFY scarr_tab INDEX sy-tabix FROM scarr_wa TRANSPORTING currcode.) in the syntax.
in both cases its working fine but i am not getting which one i have to use where to modify the internal table?
regards
SATYA

Hi Henry,
SY-INDEX is the value of the current iteration. It is applicable for the following programming constructs in ABAP -
DO...ENDDO.
WHILE...ENDWHILE.
SY-TABIX (TABle IndeX) is applicable to internal tables. If you scroll down in the link which Eddie has given, you will find a more detailed explanation for sy-tabix and which statements affect its value.
Regards,
Anand Mandalika.

Btree vs Bitmap. Optimizing load process in Data Warehouse.

Hi,
I'm working on fine tuning a Data Warehousing system. I understand that Bitmap indexes are very good for OLAP systems, especially if the cardinality is low and if the WHERE clause has multiple fields on which bitmap indexes exist for each field.
However, what I'm finetuning is not query, but load process. I want to minimize the total load time. If I create a bitmap index on a field with cardinality of one million, and if the table has one million rows (each row has a distinct field value), then my understanding is
The total size of the bitmap index = number of rows * (cardinality / 8) bytes
(because there are 8 bits in a byte).
Hence the size of my bitmap index will be
Million * Million / 8 bytes = 116 GB.
Also, does anyone know what would be the size of my B-tree index? I'm thinking
The total size of the B-tree index = number of rows * (field length+20) bytes
(assuming that the field length of rowid is 20 charas).
Hence the size of my b-tree index will be
Million * (10+20) bytes = 0.03 GB (assuming that my field length is 10 charas).
That means B-tree index is much lesser than the size of the Bitmap index.
Is my math correct? If so, then the disk activity will be much higher for a bitmap index than a B-tree index. Hence, creation of the bitmap index should take much longer than the B-tree index if the cardinality is high.
Please let me know your opinions.
Thanks
Sankar

Hi Jaffar,
Thanks to you and Jonathan. This is the kind of answer I have been looking for.
If I understand your email correctly, for the scenario from my original email, bitmap index will be 32MB where as Btree will be 23MB. Is that right?
Suppose there is an order table with 10 orders. There are four possible values for OrderType. Based on your reply, now I understand that the bitmap index is organized as shown below.
Data Table:
RowId     OrderNo     OrderType
1     23456     A
2     23457     A
3     23458     B
4     23459     C
5     23460     C
6     23461     C
7     23462     B
8     23463     B
9     23464     D
10     23465     A
Index table:
OrderType     FROM     TO
A     1     2
B     3     3
C     4     6
B     7     8
D     9     9
A     10     10
That means, you might have more entries in the index table than the cardinality. Is that right? That means, the size of the index table cannot be EXACTLY determined based on cardinality. In our example, the cardinality is 4 while there are 6 entries in the index table.
In an extreme example, if no two adjacent records have the same OrderType, then there will be 10 records in the index table as well, as shown in the example below.
Data Table (second example):
RowId     OrderNo     OrderType
1     23456     A
2     23457     B
3     23458     C
4     23459     D
5     23460     A
6     23461     B
7     23462     C
8     23463     D
9     23464     A
10     23465     B
Index table (second example):
OrderType     FROM     TO
A     1     1
B     2     2
C     3     3
D     4     4
A     5     5
B     6     6
C     7     7
D     8     8
A     9     9
B     10     10
That means, the size of the index table will be somewhere between the cardinality (minimally) and the table size (maximally).
Please let me know if I make sense.
Regards
Sankar

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

Diff b/w btree and bitmap index ?

Similar Messages

Maybe you are looking for