Re: Bitmap index limits concurency

I'm sure that bitmap indices are one of the features that are most subject to implementation changes between versions of Oracle; but this does not appear to be true in version 7.3.4 - I haven't yet tried it on any version 8 databases.

By doing block dumps it is possible to show that an index entry is locked and updated on the insert, and not at commit time.

However, I do recall reading somewhere that for array processing the index update is postponed until the entire array call completes, so that only a single bitmap recalculation has to take place (instead of 1 per row). Perhaps this is what you were thinking of.

--

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

David Sisk wrote in message <4T3u3.979$tp2.795_at_news.ipass.net>...
>
>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.
Received on Tue Aug 17 1999 - 03:35:48 CDT