8.1.7.1 
BITMAP INDEX GROWS WHILE DELETING ROS FROM A TABLE 
--------------------------------------------------------------------------------
Bit map index grows while deleting the rows from a table using the PL/SQL 
procedure which uses rowid for deleting. 
WORKAROUND: use other condition in "where" clause instead of rowid.

delayed block clean-out of deleted records  preventing those bitmap index blocks to be getting re-used before commit. index doesn't grow if we commit each time but this is not a practical  solution. and if we use the other codition instead of rowid say some date range - it doesn't grow.  
This is still an existing issue with Bitmax index which can not be easily fixed. Changing this would require large design changes.

Bug No.1279943
Database Version 8.0.6.0.0
Status Not Feasible to fix
PROBLEM:
insert into bitmap index via fast snapshot refresh ,(row-by-row conventional DML insert)
, causes the bitmap index
to use excessive amount of space, resulting in ora-1652
WORKAROUND: Rebuild index

Bug No. 630244 
8.0.3 
SINGLE-ROW UPDATE OF COLUMN CAUSES HUGE GROWTH OF BITMAP INDEX 
--------------------------------------------------------------------------------
As part of the load process in a data warehouse, customer updates a 2-valued column which has a bitmap index. These updates cause the bitmap index to grow by a factor of 200. If the index is recreated, it returns to its original size. This order of growth is consistent though in my tests the ultimate size of the index varies slightly.
Bulk updates do not cause the same behaviour. The customer validates records as part of the load and the updates occur during validation. This is an important part of their application.
WORKAROUND
commit after every update.  Committing will enable index logic to reclaim the wasted
space created by these deleted records. The best workaround is still to rewrite your application
to use bulk dml.  This may be done by creating a table to store up all the changes you intend to make.  This table should enable you to code a bulk dml statement that applies all the changes.  Since bitmap index dml is specially optimized for bulk dml this would probably be the best mechanism to rapidly apply many changes to a bitmap indexed table.
unfortunately, this is the behavior of bitmap indexes. single row
dml operations perform the maintenance to the bitmap and the implementation
of the bitmap index forces the index layer to delete/insert the row.
bulk operations are buffer by the bitmap code - there really is nothing
that we can - we would have to change the implementation of bitmap
indexes and that is not something that is likely to occur. if anything
this is an enhancement request for additional functionality.