Oracle bitmap indexes are generally used to index columns that have very sparse domains such as Y/N, gender, or any other list of member values that is small in number. You get the advantage of indexing without creating in imbalanced btree if a conventional index is used. There is lots of info on bitmap indexes. They are also very common in read-mostly applications like data warehousing.

I have a security application that has table ACCESS_LOG that logs access to person data and by whom. The only filter I had on the ACCESS_LOG within the Apex security application was on created_by, which was a relatively small number of users over time in what would ultimately become a very large table. And, the ACCESS_LOG is insert-only so it has the characteristics of a DW table. 

What we found is that concurrent access by two different users with functionality that writes to the ACCESS_LOG was causing the application to hang in the second session. Seems like an oddity for an application that only inserts into the ACCESS_LOG, not the scenario where one wold expect to find locking. The contention only happened when the value of created_by posted to the ACCESS_LOG was the same. Maddening since the procedural code doing the posting didn't have any issues and had been in production use for some time.

The mystery was resolved with my partners Andy and Jim at the University of Missouri who tracked the problem to the bitmap index on ACCESS_LOG. The problem was exposed when they started to use functionlaity that had not been used significantly before. Yet, the same procedural code was used elsewhere throughout the application and did not reveal this contention problem. Converting to a conventional index resolved the problem.

Andy and Jim had suspected a contention problem. Digging further into the documentation for Oracle 11.1, that is indeed what goes on with bitmap indexes. Oracle deals with blocks of indexes for a specific bitmap index value, not individual like in a btree index. The first session locked the block causing the second session to wait until a commit or rollback.

The conventional indexes that replaced the bitmaps may have performance issues over time. I also could not add a commit within the procedural code that did the posting due to that impacting a larger transaction. 

Lesson learned.  Even though it should have been insert only, the fact that the inserts come from multiple sessions and how Oracle processes bitmap indexes made the bitmap indexes a problem. How much of a problem we'll see.

 The other lesson learned - concurrent applications need concurrent testing with same and different data to test for issues like described above. Otherwise, the problem is hidden waiting to strike.

Bitmap indexes will return to my app in the audit tables and other places where the inserts come from one source and there is not concurrency issues.

++B