A bitmap index is a specialized database index that represents indexed values using bitmaps—sequences of binary bits (0 and 1) rather than storing a separate row pointer for every occurrence of a value.
For each distinct value of the indexed column, the index maintains a bitmap. Each logical bit position corresponds to a row location in the indexed table:
Consider:
The logical bitmap representation is:
For example:
means rows 1, 3, 5 and 7 contain ACTIVE.
This is fundamentally different from the conceptual representation of a traditional B-tree index:
whereas a bitmap index can represent membership across a range of row locations using a bitmap:
This representation becomes especially useful when a column has relatively few distinct values compared with the number of rows, and when queries combine several conditions.
For example:
AND:But there is an important Oracle-specific detail behind this simplified explanation:
Oracle does not literally maintain one enormous uncompressed bitmap where bit #1 means "table row #1", bit #2 means "table row #2", and so on.
Oracle tables do not have permanent sequential row numbers. Rows are physically identified using ROWIDs. Oracle therefore stores bitmap information in index entries associated with ranges of ROWIDs, and the bitmap represents rows within those ranges.
That is where the real internal explanation should begin.
So the progression should be:
Definition → simple bitmap example → B-tree difference → bitwise operations → Oracle ROWID-based physical implementation → compression → execution plans → DML/locking → optimizer behavior.
That will give you the detailed description you asked for without making the beginning unnecessarily complicated.