Why does performance degrade when many UPDATE, INSERT, or DELETEstatements are issued on a table...

Bitmap indexes in currently “supported” versions of Oracle are maintained in a much more efficient manner than they were previously, to the point where the need for frequently rebuilds has been much reduced, even in tables in which such indexes are not dropped during heavy loads.

That said, Bitmap indexes are still unsuitable in OLTP type environments (even in 11g or later) due to the locking implications associated with them.

Note: bitmap indexes are only suitable for static tables and materialized views which are updated at nigh and rebuilt after batch row loading.

Not B: Like b-tree indexes, bitmap indexes should be rebuilt (ALTER INDEX . . . REBUILD) if there is a lot of DML (UPDATE, INSERT, DELETE) activity.

Not A: Since 10g, Oracle is significantly more efficient and where possible will simply adjust the current rowid range of the Bitmap index entry and modify the bitmap string accordingly to accommodate a new row value (resulting in an overall increase of just 2 bytes overall in this example) rather than create a totally new index entry (which required an additional 21 bytes in the 9i example).