对于bitmap index，我们知道，同一个值会利用一个位图来进行索引。假如有如下测试表：

NING@ning>select* from test;

ID NAME
---------- --------------------
1 a
1 b
1 c
2 a
2 b
2 c

那么在ID列上建bitmap index的话，所有ID＝1的会放到一个位图中，所有ID=2的是另外一个位图，而在执行DML操作的时候，锁定的将是整个位图中的所有行，而不仅仅是DML涉及到的行。由于锁定的粒度变粗，bitmap index更容易导致死锁的发生。

下面我们利用上面的test作为例子，来演示一下bitmap index导致的deadlock：

1.建立bitmap index

NING@ning>create bitmap index ix_test on test(id);

Index created.

2.在session 1执行

NING@ning>update test set id=3 where id=1 and name='a';

1 row updated.

此时所有id=1的行都被锁定

3.在session 2执行

NING@ning>update test set id=4 where id=2 and name='a';

1 row updated.

此时所有id=2的行都被锁定

4.在session 1执行

NING@ning>update test set id=4 where id=2 and name='b';

此时会话被阻塞

5.在session 2执行

NING@ning>update test set id=3 where id=1 and name='b';

此时会话被阻塞

6.再回到session 1，发现系统检测到了死锁的发生

NING@ning>update test set id=4 where id=2 and name='b';
update test set id=4 where id=2 and name='b'
*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource

相关trace文件中的记录：

*** SESSION ID:(138.5621) 2007-03-01 10:58:00.187
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits
TX-00040001-000000ea 18 138 X 20 134 S
TX-0006002d-00000131 20 134 X 18 138 S
session 138: DID 0001-0012-00000015 session 134: DID 0001-0014-00000798
session 134: DID 0001-0014-00000798 session 138: DID 0001-0012-00000015
Rows waited on:
Session 134: obj - rowid = 00003199 - AAADGZAAAAAAAAAAAA
(dictionary objn - 12697, file - 0, block - 0, slot - 0)
Session 138: obj - rowid = 00003199 - AAADGZAAAAAAAAAAAA
(dictionary objn - 12697, file - 0, block - 0, slot - 0)
Information on the OTHER waiting sessions:
Session 134:
pid=20 serial=9803 audsid=30524 user: 27/NING
O/S info: user: BEPDG00726-XPAdministrator, term: BEPDG00726-XP, ospid: 2088:4080, machine: GDCBEPDG00726-XP
program: sqlplus.exe
application name: SQL*Plus, hash value=3669949024
Current SQL Statement:
update test set id=4 where id=1 and name='b'
End of information on OTHER waiting sessions.
Current SQL statement for this session:
update test set id=3 where id=2 and name='b'

死锁发生的根本原因是对于资源的排他锁定顺序不一致。上面的试验中，session1对于bitmap index中的2个位图是先锁定ID=1的位图，然后请求ID=2的位图，而在此之前ID=2的位图已经被session2锁定。session2则先锁定ID=2的位图，然后请求ID=2的位图，而此前ID=1的位图已经被session1锁定。于是，session1等待session2释放ID=2的位图上的锁，session2等待session1释放ID=1的位图上的锁，死锁就发生了

而如果我们创建的是普通的B*Tree index，重复上面的试验则不会出现任何的阻塞和死锁，这是因为锁定的只是DML操作涉及到的行，而不是所有ID相同的行。