Re: Bitmap index problem

A bit pessimistic there.
Each entry in the bitmap index is:

    key value, start rowid, end rowid, bitmap for rowid range.

The size of a single entry is limited to something between one third and one
half of a block. Consequently the full
bitmap for a single key value could consist of many bitmap entries.

When a row is updated, only the single
bitmap entry that covers the appropriate rowid range is locked (although as you
point out, this does mean two entries,
one for the BEFORE and one for the AFTER key values).

There are various side-effects and (sub-) optimisations in place, though, which
can
a) cause bitmap indexes to fragment

    very rapidly and
b) cause very large numbers of bitmap

    ranges to be locked concurrently.

The former is a problem even for single-user updates; the latter is a disaster for any concurrent updates.

--

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

Connor McDonald wrote in message <38D75572.680_at_yahoo.com>...


>boris wrote:

>>

>Bitmap indexes will look all rows with the same value when you issue a

>DML.  For example, if you have 5 distinct values and you update one,

>then 20% of the table is locked (until commit).

>

>If you have 2 distinct values and you update one to another - then the

>whole table is locked..

>