没有必胜的秘籍，没有方程式遵循~~
要赢~~只有全身心的投入！
晶晶实验五_讨论锁 篇
上一篇 / 下一篇 2008-02-17 22:04:50 / 个人分类：晶晶oracle实验系列
查看( 512 ) /
评论( 24 )
锁是保护和用户相关的资源,例如：表,用户,会话.
和闩比起来,锁的实现要复杂的多.锁的获取和释放也没有闩快,有些锁持有的时间会比较长,如果说TM锁和TX锁.在DML操作中,用户不提交,这两个锁就不会被释放.锁主要保护会话层面上的一些资源.理解锁的原理还是比较简单的.不过先要明白相关锁的一些数据结构.下面我们先从介绍锁相关的数据结构开始入手.
一,池
在SGA中和锁相关的内存区有两块.我分别称呼他们为'队列资源池'和'锁池'.池其实指的就是一块固定大小的内存,是计算机中经常会用到的一个计算机术语.
队列资源池:存放所有的队列资源.所有的队列锁都是队列资源.例如:一个表上的TM锁就是一个队列资源.一个数据库中可以有成千上万个表,每个表的TM锁,都是单独的一个队列资源.为了对他们加以区分,要为这各个表的TM队列资源起个名字,名字的格式'队列资源类型-id1-id2'.id1 和id2分别是两个相关某种队列资源的信息,这两个信息根据不同的队列资源类型而不同,对于TM队列资源来说,id1取值通常是表的对象编号,(可以在dba_objects视图中的object_id或data_object_id列查看).id2取值为0.也就是说对于TM类型的队列资源来说，有多少个表就有多少个TM队列资源.如果有一个表的TM队列资源被占用,他就会被放进队列资源池.队列资源池的大小可以如下命令查询得知:
SQL> select * from v$resource_limit where resource_name='enqueue_resources';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
enqueue_resources 18 46 1208 UNLIMITED
如上显示,10G中默认的队列资源池初始分配1208个条目.每个队列资源条目在池中只占很少的信息,其中主要包括:队列资源名,所有者队列链表地址,等待者队列链表地址和转换者队列链表等信息.在队列资源池中,只记录这3种队列的头地址,而一个队列资源上真正的锁信息是记录在锁池中的.例如:两个会话修改了同一个表的不同行,两个会话并不互相阻塞.表的ID是2000,这里我们以TM锁为例,会有一个新的队列资源被占用,其名字是<TM-2000-0> 他会有两个持有者,队列资源池中会有一个空闲条目被占用,其信息包括:队列资源名和持有者队列的链表头.但真正的两个持有者的相关信息,被存储在锁池中.如下命令可以显示锁池的大小:
SQL> select * from v$resource_limit where resource_name='enqueue_locks';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
enqueue_locks 18 30 2950 2950
锁池:会话持有任意一个队列资源的信息,保存在锁池中.就象上面的例子,两个会话分别持有了一个表的TM队列资源,这两个会话的信息被保存在锁池中,而队列资源信息保存在队列资源池中,队列资源信息和锁池中的各会话持有或等待某资源的信息,合在一起被称为队列锁.还以上例为准,队列资源池中的<TM-2000-0>,几个链表的头等信息,和锁池中的两个持有者的信息,合在一起,称为一个TM队列锁.下面用一个图来说明:
因为俺是新ID,好象没有发图片滴权限...
只好把图片上传到俺滴blog中 连接是:
http://space.itpub.net/13095417/viewspace-172808
大家凑合看吧.
图解如下:上图是我分别在10和12号会话修改6657表后,<TM-6657-0>的相关情况,另外,由于队列资源池中的条目较多,为了能够快速的在池中查找某一条目,所以队列资源池采用HASH表的方式进行查找.oracle将根据每个条目的队列资源名,生成一个HASH值,如果想申请某一个队列资源上的锁,会先根据HASH值,在HASH表中,查找相关的资源.上图中的7b6d5c40就是HASH表中所记载的<TM-6657-0>在资源队列池中的地址.之所以[7b6d5c40,7b6d5c40]这样的形式记载,是因为某一个HASH值所对应的队列资源可能不止一个.这将构成一个链表,中括号的两个数字,代表链表的首指针和尾指针.对某一个HASH值下链表的访问也需要enqueue hash chain闩的保护.具体的就不多说了,相关文档都有介绍.在锁池中就不需要针对锁池的HASH 表咯,因为我们不需要直接在锁池中搜索某一个持有者或等待者.两个池各有自己的Resource free链表,管理空闲的条目.明白了这些有关队列锁的数据结构,队列锁的获取和释放过程就非常简单了.这就不在详细多说,可以参考文档.
和闩比起来,锁的实现要复杂的多.锁的获取和释放也没有闩快,有些锁持有的时间会比较长,如果说TM锁和TX锁.在DML操作中,用户不提交,这两个锁就不会被释放.锁主要保护会话层面上的一些资源.理解锁的原理还是比较简单的.不过先要明白相关锁的一些数据结构.下面我们先从介绍锁相关的数据结构开始入手.
一,池
在SGA中和锁相关的内存区有两块.我分别称呼他们为'队列资源池'和'锁池'.池其实指的就是一块固定大小的内存,是计算机中经常会用到的一个计算机术语.
队列资源池:存放所有的队列资源.所有的队列锁都是队列资源.例如:一个表上的TM锁就是一个队列资源.一个数据库中可以有成千上万个表,每个表的TM锁,都是单独的一个队列资源.为了对他们加以区分,要为这各个表的TM队列资源起个名字,名字的格式'队列资源类型-id1-id2'.id1 和id2分别是两个相关某种队列资源的信息,这两个信息根据不同的队列资源类型而不同,对于TM队列资源来说,id1取值通常是表的对象编号,(可以在dba_objects视图中的object_id或data_object_id列查看).id2取值为0.也就是说对于TM类型的队列资源来说，有多少个表就有多少个TM队列资源.如果有一个表的TM队列资源被占用,他就会被放进队列资源池.队列资源池的大小可以如下命令查询得知:
SQL> select * from v$resource_limit where resource_name='enqueue_resources';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
enqueue_resources 18 46 1208 UNLIMITED
如上显示,10G中默认的队列资源池初始分配1208个条目.每个队列资源条目在池中只占很少的信息,其中主要包括:队列资源名,所有者队列链表地址,等待者队列链表地址和转换者队列链表等信息.在队列资源池中,只记录这3种队列的头地址,而一个队列资源上真正的锁信息是记录在锁池中的.例如:两个会话修改了同一个表的不同行,两个会话并不互相阻塞.表的ID是2000,这里我们以TM锁为例,会有一个新的队列资源被占用,其名字是<TM-2000-0> 他会有两个持有者,队列资源池中会有一个空闲条目被占用,其信息包括:队列资源名和持有者队列的链表头.但真正的两个持有者的相关信息,被存储在锁池中.如下命令可以显示锁池的大小:
SQL> select * from v$resource_limit where resource_name='enqueue_locks';
RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- -------------------- --------------------
enqueue_locks 18 30 2950 2950
锁池:会话持有任意一个队列资源的信息,保存在锁池中.就象上面的例子,两个会话分别持有了一个表的TM队列资源,这两个会话的信息被保存在锁池中,而队列资源信息保存在队列资源池中,队列资源信息和锁池中的各会话持有或等待某资源的信息,合在一起被称为队列锁.还以上例为准,队列资源池中的<TM-2000-0>,几个链表的头等信息,和锁池中的两个持有者的信息,合在一起,称为一个TM队列锁.下面用一个图来说明:
因为俺是新ID,好象没有发图片滴权限...
只好把图片上传到俺滴blog中 连接是:http://space.itpub.net/13095417/viewspace-172808
大家凑合看吧.
图解如下:上图是我分别在10和12号会话修改6657表后,<TM-6657-0>的相关情况,另外,由于队列资源池中的条目较多,为了能够快速的在池中查找某一条目,所以队列资源池采用HASH表的方式进行查找.oracle将根据每个条目的队列资源名,生成一个HASH值,如果想申请某一个队列资源上的锁,会先根据HASH值,在HASH表中,查找相关的资源.上图中的7b6d5c40就是HASH表中所记载的<TM-6657-0>在资源队列池中的地址.之所以[7b6d5c40,7b6d5c40]这样的形式记载,是因为某一个HASH值所对应的队列资源可能不止一个.这将构成一个链表,中括号的两个数字,代表链表的首指针和尾指针.对某一个HASH值下链表的访问也需要enqueue hash chain闩的保护.具体的就不多说了,相关文档都有介绍.在锁池中就不需要针对锁池的HASH 表咯,因为我们不需要直接在锁池中搜索某一个持有者或等待者.两个池各有自己的Resource free链表,管理空闲的条目.明白了这些有关队列锁的数据结构,队列锁的获取和释放过程就非常简单了.这就不在详细多说,可以参考文档.
TAG:
-
stronghearted
发布于2008-02-17 22:20:40
-
概念好清晰噢!
-
foxmile
发布于2008-02-18 10:06:18
-
支持。
-
bluemoon0083发布于2008-02-18 10:22:35
-
支持晶晶mm
-
lixiang114发布于2008-02-18 10:33:44
-
pub里女孩不多，一定要支持！！！
-
jlliuyi发布于2008-02-18 10:35:21
-
好文章!
-
catchwo
发布于2008-02-18 11:32:07
-
前一阵子也了解了解了队列，锁，资源。我认为这三个东西不能这样单独的区分开来理解，下面是我整理出来的一些结构希望有助于理解这三个东西
注意gv$lock,gv$_lock1,gv$enqueue_lock的定义
SELECT * FROM V$RESOURCE
SELECT * FROM V$enqueue_Lock
SELECT * FROM V$LOCK
select * from X$KSQDN - Global [D]atabase [N]ame
select * from X$KSQEQ - [E]n[Q]ueue Object
select * from X$KSQRS - Enqueue [R]e[S]ource
select * from X$KSUSE - [SE]ssion Info
select * from X$KTCXB - Transaction O[B]ject
select * from X$KTADM - D[M]L lock
select * from X$KDNSSF - [F]lush Enqueue Objects
select * from X$KSUSE - [SE]ssion Info
select * from v$fixed_view_definition where view_name like '%V%LOCK%'
GV$SESSION
select inst_id,addr,indx,ksuseser,ksuudses,ksusepro, ksuudlui,ksuudlna,ksuudoct, ksusesow, decode(ksusetrn,hextoraw('00'),null,ksusetrn), decode(ksqpswat,hextoraw('00'),null,ksqpswat), decode(bitand(ksuseidl,11),1,'ACTIVE',0, decode(bitand(ksuseflg,4096),0,'INACTIVE','CACHED'),2,'SNIPED',3,'SNIPED', 'KILLED'), decode(ksspatyp,1,'DEDICATED',2,'SHARED',3,'PSEUDO','NONE'), ksuudsid,ksuudsna,ksuseunm,ksusepid,ksusemnm,ksusetid,ksusepnm, decode(bitand(ksuseflg,19),17,'BACKGROUND',1,'USER',2,'RECURSIVE','?'), ksusesql, ksusesqh, ksusepsq, ksusepha, ksuseapp, ksuseaph, ksuseact, ksuseach, ksusecli, ksusefix, ksuseobj, ksusefil, ksuseblk, ksuseslt, ksuseltm, ksusectm, decode(bitand(ksusepfl, 16),0,'NO','YES'), decode(ksuseft, 2,'SESSION', 4,'SELECT',8,'TRANSACTIONAL','NONE'), decode(ksusefm,1,'BASIC',2,'PRECONNECT',4,'PREPARSE','NONE'), decode(ksusefs, 1, 'YES', 'NO'), ksusegrp, decode(bitand(ksusepfl,16),16,'ENABLED', decode(bitand(ksusepfl,32),32,'FORCED','DISABLED')), decode(bitand(ksusepfl,64),64,'FORCED', decode(bitand(ksusepfl,128),128,'DISABLED','ENABLED')), decode(bitand(ksusepfl,512),512,'FORCED', decode(bitand(ksusepfl,256),256,'DISABLED','ENABLED')), ksusecqd, ksuseclid
from x$ksuse
where bitand(ksspaflg,1)!=0 and bitand(ksuseflg,1)!=0
GV$RESOURCE
select inst_id,addr,ksqrsidt,ksqrsid1,ksqrsid2 from x$ksqrs where bitand(ksqrsflg,2)!=0
GV$_LOCK1
select inst_id,addr,ksqlkadr,ksqlkses,ksqlkres,ksqlkmod,ksqlkreq, ksqlkctim, ksqlklblk
from x$kdnssf where bitand(kssobflg,1)!=0 and (ksqlkmod!=0 or ksqlkreq!=0)
union all
select inst_id,addr,ksqlkadr,ksqlkses,ksqlkres,ksqlkmod,ksqlkreq, ksqlkctim, ksqlklblk
from x$ksqeq where bitand(kssobflg,1)!=0 and (ksqlkmod!=0 or ksqlkreq!=0)
GV$_LOCK
select USERENV('Instance'),laddr,kaddr,saddr,raddr,lmode,request,ctime, block from v$_lock1
union all select inst_id,addr,ksqlkadr,ksqlkses,ksqlkres,ksqlkmod,ksqlkreq, ksqlkctim,ksqlklblk
from x$ktadm where bitand(kssobflg,1)!=0 and (ksqlkmod!=0 or ksqlkreq!=0)
union all select inst_id,ktcxbxba,ktcxblkp,ksqlkses,ksqlkres,ksqlkmod,ksqlkreq, ksqlkctim,ksqlklblk
from x$ktcxb where bitand(ksspaflg,1)!=0 and (ksqlkmod!=0 or ksqlkreq!=0)
GV$LOCK
select /*+ ordered use_nl(l), use_nl(s), use_nl(r) +*/ s.inst_id, l.laddr, l.kaddr, s.ksusenum, r.ksqrsidt, r.ksqrsid1, r.ksqrsid2, l.lmode, l.request,l.ctime, decode(l.lmode, 0, 0, l.block)
from v$_lock l,x$ksuse s,x$ksqrs r
where l.saddr=s.addr and l.raddr=r.addr
GV$ENQUEUE_LOCK
select /*+ ordered use_nl(l), use_nl(s), use_nl(r) +*/ s.inst_id,l.addr,l.ksqlkadr,s.ksusenum,r.ksqrsidt,r.ksqrsid1,r.ksqrsid2, l.ksqlkmod, l.ksqlkreq,l.ksqlkctim,l.ksqlklblk
from x$ksqeq l,x$ksuse s,x$ksqrs r
where l.ksqlkses=s.addr and bitand(l.kssobflg,1)!=0 and (l.ksqlkmod!=0 or l.ksqlkreq!=0) and l.ksqlkres=r.addr
1 每条ddl语句开始时[commit|rollback],begin with a transaction,end with[commit|rollback]
2 row-level lock 事务TX[X]
a 开始时检查是否能获得所有row-level lock
b 如果能则lock
c 如果不能 则进入 TX[1] 等待LIST,此时并不设置任何row-level lock
d TX[1]释放触发等待LIST检查此时TX[X]再次进入步骤[a],如果有其他TX锁定了相关数据则TX[X]再次进入等待LIST
2 DML LOCK IS TYPE OF TM LOCK
3 LOCK 来源
KT [T]ransaction Layer
Table [A]ccess [D]efinition
X$KTADM - D[M]L lock
[C]ontrol Component
X$KTCXB - Transaction O[B]ject
KG [G]eneric Layer------library cache lock and pin
[L]ibrary Cache Manager ( defined and mapped from kqlf )
Object Locks
X$KGLLK - Object [L]oc[K]s
Object Pins
X$KGLPN - Object [P]i[N]s
KS En[Q]ueue Management------enqueue lock
X$KSQEQ - [E]n[Q]ueue Object
KD [D]ata Layer
Sequence [N]umber Component
[S]equence Enqueues - common area for enqueue objects
X$KDNSSF - [F]lush Enqueue Objects - 7.2 or lower
-
晶晶小妹
发布于2008-02-18 12:15:52
-
回7楼的前辈:
先说第一句,队列,锁,资源这三个概念我没有分开来理解吖?这三个合在一起就是队列锁.队列和资源其实一个概念,我称他们为队列资源,用来存储队列资源的内存大小可以通过 v$resource_limit查询enqueue_resources得到.这一部分也就是我所说的队列资源池,某一个队列资源上的等待者 持有者和转换者相关的信息,并不在队列资源池中存储,而在另外一块内存中存储,大小可以在v$resource_limit视图中enqueue_locks查到.也就是我所说的锁池,锁池和队列资源池中的信息合一起 称呼为一个队列资源锁.
所有的队列资源池中的条目都在x$ksqrs中存储.在v$resource显示正在被使用的条目,锁池中正在被使用的条目可以在x$ksqeq中看到,正在被使用的在v$enqueue_lock中显示,但是TM和TX这两个队列锁和其他的不一样,除非他们发生了 enqueue等待,否则他们并不在x$ksqeq中显示,oracle使用不同的结构来管理TM和TX. TX的是x$ktcxb.它是 v$transaction_enqueue的基础视图.它的尺寸有transactions 这个初始化参数控制.TM 是x$ktadm 尺寸由 DML_LOCKS定义也就是TM锁的数量,x$ktadm意义不大可以为我们提供锁的模式,加锁的时间，正在请求的模式,会话SID等信息.信息量并不比v$lock中的多.通过以上两个X$视图观察正在使用中的TM,TX锁的最好办法是,
set linesize 800
col KTCXBNAM for a20
select * from x$ktcxb where ktcxblkp in(select kaddr from v$lock where type='TX');
select * from x$ktadm where ksqlkadr in(select kaddr from v$lock where type='TM');
我觉的有关于锁的X$视图,意义不是太大,他们所能提供的信息,要么是晦涩难懂,要么已经可以通过v$视图很方便的看到.
TX锁涉及事务,在以后的晶晶实验系列中,会找一篇详细介绍的.
-
foxmile
发布于2008-02-18 12:23:42
-
好。大家鼓掌。感谢老虎、eygle、biti。。。。。
-
teddyboy发布于2008-02-18 12:25:09
-
小晶晶好pp啊!
[ 本帖最后由 teddyboy 于 2008-2-18 12:42 编辑 ]
-
晶晶小妹
发布于2008-02-18 13:12:07
-
QUOTE:
原帖由 foxmile 于 2008-2-18 12:23 发表
好。大家鼓掌。感谢老虎、eygle、biti。。。。。
-
BTxigua
发布于2008-02-18 13:15:06
-
牛！！！！！
有潜力。
-
cyt2005发布于2008-02-18 13:36:47
-
up~
-
catchwo
发布于2008-02-18 13:46:01
-
QUOTE:
原帖由 晶晶小妹 于 2008-2-18 12:15 发表
回7楼的前辈:
先说第一句,队列,锁,资源这三个概念我没有分开来理解吖?这三个合在一起就是队列锁.队列和资源其实一个概念,我称他们为队列资源,用来存储队列资源的内存大小可以通过 v$resource_limit查询enqueue_resources得到.这一部分也就是我所说的队列资源池,某一个队列资源上的等待者 持有者和转换者相关的信息,并不在队列资源池中存储,而在另外一块内存中存储,大小可以在v$resource_limit视图中enqueue_locks查到.也就是我所说的锁池,锁池和队列资源池中的信息合一起 称呼为一个队列资源锁.
所有的队列资源池中的条目都在x$ksqrs中存储.在v$resource显示正在被使用的条目,锁池中正在被使用的条目可以在x$ksqeq中看到,正在被使用的在v$enqueue_lock中显示,但是TM和TX这两个队列锁和其他的不一样,除非他们发生了 enqueue等待,否则他们并不在x$ksqeq中显示,oracle使用不同的结构来管理TM和TX. TX的是x$ktcxb.它是 v$transaction_enqueue的基础视图.它的尺寸有transactions 这个初始化参数控制.TM 是x$ktadm 尺寸由 DML_LOCKS定义也就是TM锁的数量,x$ktadm意义不大可以为我们提供锁的模式,加锁的时间，正在请求的模式,会话SID等信息.信息量并不比v$lock中的多.通过以上两个X$视图观察正在使用中的TM,TX锁的最好办法是,
set linesize 800
col KTCXBNAM for a20
select * from x$ktcxb where ktcxblkp in(select kaddr from v$lock where type='TX');
select * from x$ktadm where ksqlkadr in(select kaddr from v$lock where type='TM');
我觉的有关于锁的X$视图,意义不是太大,他们所能提供的信息,要么是晦涩难懂,要么已经可以通过v$视图很方便的看到.
TX锁涉及事务,在以后的晶晶实验系列中,会找一篇详细介绍的.
不错
这段说明非常好！晶晶是个高手
回“我觉的有关于锁的X$视图,意义不是太大,他们所能提供的信息,要么是晦涩难懂,要么已经可以通过v$视图很方便的看到.”
我是用来发掘三者的关系
-
晶晶小妹
发布于2008-02-18 13:49:35
-
谢谢１４楼前辈的夸奖，嘻嘻～～
努力ing
＾＿＾
-
xilangxiangwa
发布于2008-02-18 14:02:33
-
先学习了你的这种钻研精神,有时间再来学习你的钻研成果.
-
wangfans
发布于2008-02-18 15:24:50
-
支持
-
halfh2o发布于2008-02-19 10:00:35
-
学习心得，支持．
-
fat_fish发布于2008-02-19 10:16:36
-
支持
-
lkypy发布于2008-03-12 15:38:34
-
学习。。。
-
lkypy发布于2008-03-13 12:41:01
-
继续学习中
-
SingleLove
发布于2008-03-13 13:26:57
-
不错，以前对锁只是一些表面的理解。看了晶晶姑娘的帖子让我又有了新的认识！！支持
-
bartfj
发布于2008-03-26 10:51:06
-
对锁了解一点了,谢谢晶晶
-
linjia828
发布于2008-03-26 11:14:24
-
晶晶写的不错，期待下篇关于X锁涉及事务的文档
-
xiaodong_1567
发布于2008-04-13 15:09:09
-
也来支持一下
