Re: Bitmap index limits concurency

This is almost inevitable with bitmap indices. If you dump a leaf block you will find that an entry looks like:

    key-value, starting rowid address, ending rowid address, bitstring

Inserting a single row, therefore, effectively locks an entire rowid range. This means that all the rows in a block (even the ones that do not yet exist)
are locked when you insert one row into that block.

You probably won't even improve the situation by setting multiple free lists, because the most current used table blocks are likely to be consecutive blocks in the segment, all covered in the same rowid range.

--

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

Mark Wagoner wrote in message <37b8251e.234365109_at_news.iac.net>...
>We have found a strang problem regarding inserts into a table with
>bitmapped indexes. If two or more transactions attempt an instert, it
>seems the latter inserts are blocked until the first transaction is
>commited. If we drop all the bitmap indexes (there are four, dropping
>1-3 has no effect) this problem goes away. Regular indexes also exist
>against this table and they cause no problem.
Received on Mon Aug 16 1999 - 10:07:12 CDT