Whereas a B*Tree index has individual entries for each row in a table so that updating a table row only causes us to lock one index entry, a bitmap index has a string of bits describing (in your example) the ‘maleness’ of all rows in the table and a different string of bits describing the ‘femaleness’ of all rows. When you update the index (because you’ve updated the table) you take a lock on the string of bits -technically known as the bitmap segment. Importantly, however, the string of bits has to be broken up so that it fits into different Oracle blocks… and an update to one block’s-worth of the string of bits doesn’t cause the other blocks’ contents to be locked.

If you consider that an 8K block can store about 65,000 bits; and if you work with the rough assumption that one bit describes the maleness of rows and one bit describes femaleness, then an 8K block can store a bitmap segment for males/females that covers about 30,000 rows in the table. When you update one row in the table, you find the bit in a bitmap segment that references that row, and you lock that entire bitmap segment in order to update that one bit. That has the effect of locking the approximately 30,000 rows in the table also covered by that bitmap segment. But it doesn’t lock the Lord knows how many other rows that are not covered by that bitmap segment.

Now, that’s extremely bad news if you are an OLTP environment and need highly concurrent DML taking place on that table, but it’s definitely not the entire table being locked, and if your table had 50 billion rows in it, you might well not notice 30,000 of them being locked for one update!

Yes, bad if it is the only bitmap index on a table, but possibly good if there are others that can be ‘ANDed’ away with the gender bitmap to give a very small set of rows. That said though I have never bitmap indexed gender