Re: When to use bitmap index based on cardinality

Actually it could lock the whole table, if you have only two values, you have to be changing from one to the other, so both bitmaps will have to be locked.

In fact the documentation is a little misleading. The bitmap is stored as a number of sections inside a b-tree whose nominal key value is a three column entry of the form:

        bitmap column, rowid range start, rowid range end

with the bitmap corresponding to the rowid range stored as a data value within the b-tree (a bit like data existing inside an IOT in Oracle 8).

Consequently what you actually lock is 'only' two sets of rowid ranges. There is also a limit on the physical size of the map component on each entry- something like 1/3 of a block.

I understand that when a bulk update occurs, the index update is delayed in some way to minimise the work done in correcting the bitmaps.

Jonathan Lewis
Yet another Oracle-related web site: www.jlcomp.demon.co.uk

Connor McDonald wrote in message <36C3ED7B.2444_at_bhp.com.au>...
>
>My understanding is that when you update a value, all rows in the table
>that have that value will also be locked....Thus if your table has two
>distinct values, then updating one row could conceivably lock half the
>table...
>
Received on Fri Feb 12 1999 - 03:24:45 CST