Bitmap Index and Update

ydd.corp.sp1.com has multiple sessions running the same queries for hours.

 The dominant waits are enq: TX row lock contention

 There are multiple sessions with similar sql_id. All but one are waiting. The same query has very high execution count (5,026,916) and high physical IO (115,218,266 blocks).

The query is a very simple UPDATE. v$sql_plan_monitor for one execution shows that only one row satisfied the update condition. But at update step, there was relatively very large physical IO read requests (631 here). Why did it take 631 physical IO requests to update a single row? Notes: additional IO metrics appeared on UPDATE plan step are frequently related to index maintenance.

 The target table has 68M rows, 704K blocks.

Surprised to see there is one BITMAP index on column CURRENT_FLAG, which is one of the columns to be updated. It is strange to have a single BITMAP index. BITMAP index works better when there are multiple BITMAP indexes which can take advantage of bitmap operations like AND/OR. Compared to the table size, the leaf blocks some indexes are pretty large. Consider rebuilding them.

Bitmap Index Leaf Block Format and Update

Each value in the index is represented by one or more bitmaps. Each bitmap represents a range of ROWIDs. Each leaf row entry typically contains four columns:
Column Value Start ROWID End ROWID Bitmap (one bit represents one ROWID)

(Source: juliandyke.com) When update an index, the row entry contains the concerned ROWID will be locked. With one bit representing one row, one row entry could represent a lot of rows, which will be locked. Concurrent updates from multiple sessions on bitmap indexes will have much larger chance for TX contentions and even deadlocks than Btree indexes. Concurrent bitmap index updates could also lead to fragmentations. For example, dba_segments indicates this bitmap index has 5,742,720 blocks and more than 44GB, although dba_indexes shows only 28,495 leaf blocks, with level of 14.

 Where is the source of high physical IO? From one hour AWR segment statistics, 99% of physical reads are from the BITMAP index. AWR SQL statistics for the same period indicates the UPDATE SQL is the dominant physical IO consumer. (The first SQL 9qqqzp4xbywd1 is the procedure invoking the UPDATE SQL).

Explain the Physical and Logic IO

The column CURRENT_FLAG has only 3 distinct values, with no NULL values. During the value update of a single row, although it does not take much effort using other index to locate the row, the update will need scan the bitmap indexes entries for the old value and the new value. There are 28,495 leaf blocks, so on average, each update will scan 28,495*2/3 = 18,996 blocks. For a single row update, this is not a small number. Same could be true even for BTREE index for column with low cardinality.

Summary
A single bitmap index on column with low cardinality is not very useful for queries. A large number of concurrent updates on the bitmap index could cause TX contentions, deadlocks and inefficient physical IO and logic IO. A better strategy is batch update from a single session. An alternative is to disable the index during update and rebuild it later.