Oracle多粒度封闭机制研究(二)-入门底子[Oracle防范]
本文“Oracle多粒度封闭机制研究(二)-入门底子[Oracle防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
1.1.1v$locked_object视图
v$locked_object视图列出当前系统中哪些对象正被锁定,其主要字段阐明以下:
|
字段名称 |
范例 |
阐明 |
|
XIDUSN |
NUMBER |
回滚段号; |
|
XIDSLOT |
NUMBER |
槽号; |
|
XIDSQN |
NUMBER |
序列号; |
|
OBJECT_ID |
NUMBER |
被锁对象标识; |
|
SESSION_ID |
NUMBER |
持有锁的会话（SESSION）标识; |
|
ORACLE_USERNAME |
VARCHAR2（30） |
持有该锁的用户的Oracle用户名; |
|
OS_USER_NAME |
VARCHAR2（15） |
持有该锁的用户的操作系统用户名; |
|
PROCESS |
VARCHAR2（9） |
操作系统的进程号; |
|
LOCKED_MODE |
NUMBER |
锁情势,取值同表三中的LMODE; |
表五:v$locked_object视图字段阐明
1.2监控脚本
按照上述系统视图,可以编制脚本来监控数据库中锁的情况.
1.2.1showlock.sql
第一个脚本showlock.sql,该脚本通过衔接v$locked_object与all_objects两视图,显示哪些对象被哪些会话锁住:
|
/* showlock.sql */ column o_name format a10 column lock_type format a20 column object_name format a15 select rpad(oracle_username,10) o_name,session_id sid, decode(locked_mode,0,'None',1,'Null',2,'Row share', 3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive') lock_type, object_name ,xidusn,xidslot,xidsqn from v$locked_object,all_objects where v$locked_object.object_id=all_objects.object_id; |
1.2.2showalllock.sql
第二个脚本showalllock.sql,该脚本主要显示当前全部TM、TX锁的信息;
|
/* showalllock.sql */ select sid,type,id1,id2, decode(lmode,0,'None',1,'Null',2,'Row share', 3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive') lock_type,request,ctime,block from v$lock where TYPE IN('TX','TM'); |
2Oracle多粒度封闭机制示例
以下示例均运行在Oracle 8.1.7上,数据库版本差别,其输出后果也大概有所差别.首先成立3个会话,此中两个（以下用SESS#1、SESS#2表示）以SCOTT用户连入数据库,以操作Oracle供应的示例表（DEPT、EMP）;另一个（以下用SESS#3表示）以SYS用户连入数据库,用于监控;
2.1操作同一行数据引发的锁阻塞
|
SESS#1: SQL> select * from dept for update; DEPTNO DNAMELOC ---------- -------------- ------------- 10 account70 20 research8 30 sales8 40 operations8 SESS#3: SQL> @showlock O_NAMESID LOCK_TYPEOBJECT_NAMEXIDUSN XIDSLOT XIDSQN ---------- ----- --------------- --------------- ------ ------- ------ SCOTT17 Row shareDEPT 825861 SQL> @showalllock SID TYID1ID2 LOCK_TYPEREQUESTCTIMEBLOCK ----- -- ---------- ---------- --------------- ---------- ---------- ---------- 17 TX5242905861 Exclusive07610 17 TM329700 Row share07610 |
如第一个脚本showlock所示,履行完SELECT…FOR UPDATE语句后,SESS#1（SID为17）在DEPT表上得到Row share锁;如第二个脚本showalllock所示,SESS#1得到的TX锁为Exclusive,这些都考证了上面的理论解析.别的,我们可以将TX锁的ID1按以下办法举行分化:
|
SQL> select trunc(524290/65536) xidusn,mod(524290,65536) xidslot from dual; XIDUSN XIDSLOT ------ ------- 82 |
分化后果与第一个脚本直接查出来的XIDUSN与XIDSLOT相同,而TX锁的ID2（5861）与XIDSQN相同,可见当LOCK TYPE为TX时,ID1实际上是该事件所占用的回滚段段号与事件表中的槽（SLOT）号的组合,ID2即为该槽被重用的次数,而这三个值实际上可以唯一地标识一个事件,即TRANSACTION ID,这三个值从系统表v$transaction中也可查到.
别的,DEPT表中有4条记录被锁定,但TX锁只有1个,这也与上面的理论解析一致.持续举行操作:
|
SESS#2: SQL> update dept set loc=loc where deptno=20; |
该更新语句被阻塞,此时再查看系统的锁情形:
|
SESS#3: SQL> @showlock O_NAMESID LOCK_TYPEOBJECT_NAMEXIDUSN XIDSLOT XIDSQN ---------- ----- --------------- --------------- ------ ------- ------ SCOTT17 Row shareDEPT 825861 SCOTT19 Row ExclusiveDEPT 000 SQL> @showalllock SID TYID1ID2 LOCK_TYPEREQUESTCTIMEBLOCK ----- -- ---------- ---------- --------------- ---------- ---------- ---------- 17 TX5242905861 Exclusive034621 17 TM329700 Row share034620 19 TM329700 Row Exclusive070 19 TX5242905861 None670 |
在DEPT表上除了SESS#1（SID为17）持有Row share锁外,又增添了SESS#2（SID为19）持有的Row Exclusive锁,但还没有为SESS#2分配回滚段（XIDUSN、XIDSLOT、XIDSQN的值均为0）;而从第二个脚本看到,SESS#2的TX锁的LOCK_TYPE为None,其申请的锁范例（REQUEST）为6（即Exclusive）,而其ID1、ID2的值与SESS#1所持有的TX锁的ID1、ID2相同,SESS#1的TX锁的阻塞域（BLOCK）为1,这就阐明了由于SESS#1持有的TX锁,阻塞了SESS#2的更新操作（SESS#2所更新的行与SESS#1所锁定的行相冲突）.还可以看出,SESS#2先申请表级的TM锁,后申请行（事件）级的TX锁,这也与前面的理论解析一致.
以上是“Oracle多粒度封闭机制研究(二)-入门底子[Oracle防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“Oracle多粒度封闭机制研究(二)-入门底子”更多相关内容
中查找“Oracle多粒度封闭机制研究(二)-入门底子”更多相关内容