Re: Tx lock problem with bitmap index

I suggest you look at my article on
www.dbazine.com about bitmap indexes
for a detailed explanation of what you are seeing.

Bottom line - you don't do single row
processing with bitmap indexes in place, and you don't do concurrent processing
with bitmap indexes in place.

To split hairs - it's not a limitation, it's a restriction. (i.e. It's not a problem by accident, it's a necessary implementation detail of the feature).

--
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html





Saikat Chakraborty wrote in message
<1f619969025c2aa41c6f1e8ef513c8b6.16981_at_mygate.mailgate.org>...


>Hi,

>I am facing a possible oracle limitation in Oracle 8.1.6 (Solaris 7)

in


>bitmap index. Unfortunately upgrade is not an option. The problem is

as


>follows:

>

>create table atest

>(

>a varchar2(10),

>b number(10)

>);

> I created a bitmap index on the column a. No Primary key or any

>constraint is present on the table. Now from two separate sessions,

>I issue the same insert statement:

>

>insert into atest values('A',10);

>

>If the first session does not commits, the second insert gets locked.

>Tracing shows only the insert is locked. Looks like the Bitmap index

can


>not work with concurrent two inserts. But does not inserts should not

be


>locked?

>Recreating the indexes as B-tree index makes the problem go away.

>Any insights will be helpful.

>

>Thanks and Regards,

>

>Saikat Chakraborty

>

>

>--

>Posted via Mailgate.ORG Server - http://www.Mailgate.ORG