Re: Oracle deadlock on table with indexes.

I'm not sure if it's as easy as that as the problem I was encountering was due to the nature of the tables being used rather than the application (type).
The table's entries typically have a single update, read and delete. Thus two transactions out of the three involved table changes.

From my reading bitmap indexes are far better for tables that have a lot of reads and very few changes.

I'm guessing (from the experience I've just had) that if a single process is updating/deleting from a table with a bitmap index, then there will be no clashes (obviously), or if multiple processes are running in different areas of the table, then (possibly) they would be okay too.

We occasionally got a clash in rows, but this should not have mattered because when process 'A' does it's delete, it would find process 'B' had removed it. The bitmap index however caused this situation to result in a deadlock - not so with a plain index.

But this is supposition based on experience.

"Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:<cdlht6$9ch$1_at_nntp.fujitsu-siemens.com>...
> "Paul" <paulz_at_cavendish.co.uk> schrieb im Newsbeitrag news:a4ca837.0407210243.c75eab0_at_posting.google.com...
> > The index was actually set by someone other than myself on a different
> > site.
> > When I comapred the indexes given VC's message, I noted that on one
> > index they had set a bitmap. I changed this to a bog-standard index
> > (non-unque in my case) and the deadlock dissapeared.
> >
> > Hope this helps!
> Just trying to learn. I had hoped that there was some magic solution allowing you
> to keep the bitmap indexes.
> Would that mean that bitmap indexes aren't good for OLTP systems?
>
> Lots of Greetings!
> Volker
Received on Thu Jul 22 2004 - 11:15:54 CDT