ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Bitmap index引发的死锁

Bitmap index引发的死锁

原创 Linux操作系统 作者:NinGoo 时间:2019-04-11 13:27:05 0 删除 编辑

对于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相同的行。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/193161/viewspace-50292/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2004-12-07

  • 博文量
    80
  • 访问量
    57322