Here are some restrictions and tips on using BI (extracted from Metalink articles)
----------------------------------------

Restrictions:

- Not used by the rule-based optimizer.

- Cannot be used on a partitioned table as a global index.

- No online build/rebuild support for bitmap indexes

- Bitmap indexes cannot be used for referential integrity checking

- A bitmap index cannot be declared as UNIQUE.

- Until 9i, you cannot specify BITMAP when creating an index-organized table.
  Oracle9i supports bitmap indexes on index-organized tables: a mapping table is
  required for creating bitmap indexes on an IOT.

- You cannot specify BITMAP for a domain index. 

- For bitmap indexes with direct load, the "SORTED_INDEX" flag does not apply


When to use?

- The column has a low cardinality: few distinct value

- Bitmapped indexes are especially helpful for complex ad hoc queries with
  lengthy WHERE clauses or aggregate queries (containing SUM, COUNT, or other
  aggregate functions)

- The table has many rows (with 1.000.000 rows is 10.000 distinct values
  possibly acceptable) 

- The environment is data warehouse-oriented (DSS system). Bitmap indexes are
  not ideal for online transaction processing (OLTP) environments because of
  their locking behavior. This is a serious disadvantage when there are many 
  UPDATE, INSERT or DELETE statements being issued by users. It is not a problem 
  when data is loaded or updated in bulk actions, as in data warehouse systems. 


Tips:

- Declaring NOT NULL constraints on all possible columns will reduce storage 
  requirements because there will not have to be a bitmap for the NULL
  values 

- Using fixed length datatypes will reduce storage requirements

- Increasing the CREATE_BITMAP_AREA_SIZE initialization parameter can
  speed query processing. This parameter determines the amount of memory allocated 
  for bitmap creation. 

- Increasing the "BITMAP_MERGE_AREA_SIZE" initialization parameter will
  speed range scans of the index.