Re: Bitmap index limits concurency

Hi Mark:

B-tree indexes are maintained on each transaction to their associated table, so concurrent updates are fine. Bitmap indexes, however, aren't maintained until you perform a commit. The data to be maintained is accumulated in (I believe) a memory segment in that session's memory, then applied to the index when the commit is issued. They work fine with single-threaded batch changes, but concurrent changes from multiple session will generate locking issues.

Jonathan's answer is also right on the money.

Hope this helps.

Regards,

--
David C. Sisk
Need tech info on Oracle? Visit The Unofficial ORACLE on NT site at http://www.ipass.net/~davesisk/oont.htm Like original music? Listen to song samples and buy a CD at http://www.mp3.com/disparityofcult

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.
>
>Has anyone else seen this? We are using 8.0.5.1.5 on NT.
>--
>Mark Wagoner
>To reply, remove no.spam from my e-mail address
Received on Mon Aug 16 1999 - 21:46:07 CDT