Why does performance degrade when many UPDATE, INSERT, or DELETEstatements are issued on a table
that has an associated bitmap index?
A.
The DML operations re-create the bitmap index blocks.
B.
The bitmap index is rebuilt automatically after a DML operation.
C.
The smallest amount of a bitmap that can be locked is a bitmap segment.
D.
Additional time is taken to remove NULL values from the bitmap index alter a DML operation.
Explanation:
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).