ITPub博客

首页 > 应用开发 > IT综合 > 有关lock的一点测试总结!

有关lock的一点测试总结!

原创 IT综合 作者:warehouse 时间:2008-04-09 11:28:23 0 删除 编辑

理解oracle lock的概念,有助于理解多用户的并发执行。

[@more@]

测试过程1:
--===========================================================================
1.测试表t是一个存在200w左右数据的大表,数据完全来自dba_objects
session1:
22:52:28 SQL> select count(object_id) from t;

COUNT(OBJECT_ID)
----------------
2019072

已用时间: 00: 00: 01.20
22:21:46 SQL> create index idx_t on t(object_id);
执行上面create index语句,保证能持续一段时间,以便在session2,3,4中进行其他操作
session:
检测在t上都加了什么类型的lock
SQL> SELECT sid,type,LMODE,
2 decode(lmode ,0 , 'none',1,'null',2,'row share',
3 3,'row exclusive',4,'share',5,'share row exclusive',6,
4 'exclusive') lock_type , request,ctime ,block
5 from v$lock
6 where type in ('TX','TM');

SID TY LMODE LOCK_TYPE REQUEST CTIME BLOCK
---------- -- ---------- ------------------- ---------- ---------- ----------
139 TM 4 share 0 3 0
139 TM 3 row exclusive 0 3 0
139 TX 6 exclusive 0 3 0

SQL>
session3:
尝试执行dml操作:
SQL> insert into t(id ,name) values(1,'a');
一直等待,被阻塞
session4:
尝试执行ddl操作:
SQL> drop table t;
drop table t
*
第 1 行出现错误:
ORA-00054: 资源正忙, 但指定以 NOWAIT 方式获取资源, 或者超时失效


SQL>
--===========================================================================
测试过程2:
session1:
22:23:14 SQL> alter index idx_t rebuild;
重新index保证能持续一段时间,以便在session2,3,4中进行其他操作
session2:
SQL> /

SID TY LMODE LOCK_TYPE REQUEST CTIME BLOCK
---------- -- ---------- ------------------- ---------- ---------- ----------
139 TM 4 share 0 3 0

SQL>
session3:
SQL> insert into t(id ,name) values(1,'a');
一直等待,被阻塞
session4:
SQL> drop table t;
drop table t
*
第 1 行出现错误:
ORA-00054: 资源正忙, 但指定以 NOWAIT 方式获取资源, 或者超时失效


SQL>
--===========================================================================
测试过程3:
session1:
22:30:21 SQL> alter index idx_t rebuild online;
在线重新index保证能持续一段时间,以便在session2,3,4中进行其他操作
session2:
SQL> /

SID TY LMODE LOCK_TYPE REQUEST CTIME BLOCK
---------- -- ---------- ------------------- ---------- ---------- ----------
139 TM 2 row share 0 2 0
139 TM 4 share 0 2 0
139 TX 6 exclusive 0 2 0
session3:
SQL> insert into t(id ,name) values(1,'a');

已创建 1 行。
SQL> select sid from v$mystat where rownum=1;

SID
----------
136
说明在在线重建index期间,可以执行dml操作
session4:
SQL> drop table t;
drop table t
*
第 1 行出现错误:
ORA-00054: 资源正忙, 但指定以 NOWAIT 方式获取资源, 或者超时失效
--==========================================================================
在session3成功执行之后既不commit也不rollback,再到session2中查看一下lock的使用情况:
SQL> /

SID TY LMODE LOCK_TYPE REQUEST CTIME BLOCK
---------- -- ---------- ------------------- ---------- ---------- ----------
139 TM 2 row share 0 16 0
139 TM 4 share 0 16 0
136 TM 3 row exclusive 0 12 0
139 TX 6 exclusive 0 16 0
139 TX 6 exclusive 0 5 0
136 TX 6 exclusive 0 9 0

已选择6行。

过一段时间初步估计在session1中的alter index idx_t rebuild online;操作应该能完成的时间之后再

来session2中监控一下:
SQL> /

SID TY LMODE LOCK_TYPE REQUEST CTIME BLOCK
---------- -- ---------- ------------------- ---------- ---------- ----------
139 TX 0 none 4 373 0
139 TM 2 row share 0 391 0
139 TM 4 share 0 391 0
136 TM 3 row exclusive 0 387 0
139 TX 6 exclusive 0 391 0
136 TX 6 exclusive 0 384 1

已选择6行。

SQL>
发现第一行lock的lock_type由原来的2变成了0也就是说现在session1的操作进行到即将结束时不能在

session3插入的那条新数据insert into t(id ,name) values(1,'a')上获得row exclusive lock而被阻

塞了,立即在session3中commit
session3:
SQL> commit;

提交完成。

SQL>
发现session1中被阻塞的alter index idx_t rebuild online;操作也马上执行完毕了
session1:
22:30:21 SQL> alter index idx_t rebuild online;

索引已更改。

已用时间: 00: 14: 19.31
再回到session2中看看lock的监控情况:
SQL> /

未选定行

SQL>
一切都释放了!
--====================================================================
上面的现象如何解释,我想用doc上的一段话很容易就解释清楚了
doc连接如下:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#sthref2043
仔细看下面列出的表格,看看到底那些表锁能相互兼容那些不可以!
Table 13-3 Summary of Table Locks

SQL Statement Mode of Table Lock Lock Modes Permitted?
RS RX S SRX X
SELECT...FROM table...
none
Y
Y
Y
Y
Y

INSERT INTO table ...
RX
Y
Y
N
N
N

UPDATE table ...
RX
Y*
Y*
N
N
N

DELETE FROM table ...
RX
Y*
Y*
N
N
N

SELECT ... FROM table FOR UPDATE OF ...
RS
Y*
Y*
Y*
Y*
N

LOCK TABLE table IN ROW SHARE MODE
RS
Y
Y
Y
Y
N

LOCK TABLE table IN ROW EXCLUSIVE MODE
RX
Y
Y
N
N
N

LOCK TABLE table IN SHARE MODE
S
Y
N
Y
N
N

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE
SRX
Y
N
N
N
N

LOCK TABLE table IN EXCLUSIVE MODE
X
N
N
N
N
N


RS: row share

RX: row exclusive

S: share

SRX: share row exclusive

X: exclusive

*Yes, if no conflicting row locks are held by another transaction. Otherwise, waits occur.

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

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

注册时间:2007-12-07

  • 博文量
    717
  • 访问量
    5366292