为什么锁定升级发生了 [英] why lock escalation happened

查看:77
本文介绍了为什么锁定升级发生了的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们在64位窗口上使用db2 udb v8.1,这条消息是在
db2diag.log文件中


ADM5502W升级38200的桌子上的锁xxx.xxx锁定

意图X成功。

目前我有locklist = 1075,maxlock = 60,所以基于公式


(((持有锁定* 36)/(锁定列表) * 4096))* 100),我有答案是

31,与maxlock 60比较,我仍然应该有锁的空间

增长,所以为什么这一点升级发生了吗?

解决方案



" xixi" <哒**** @ yahoo.com>在消息中写道

news:c0 ************************** @ posting.google.c om ...

我们在64位窗口上使用db2 udb v8.1,此消息在db2diag.log文件中


ADM5502W升级 38200"桌子上的锁xxx.xxx锁定
意图X成功了。

目前我有locklist = 1075,maxlock = 60,所以基于公式

(((持有锁* 36)/(locklist * 4096)) * 100),我的答案是答案是31,与maxlock 60相比,我还应该有锁的空间来增长,那为什么这一点会升级呢?




在64位DB2上锁定为56个字节,而不是36个。这意味着这些38200锁定

占锁定列表的48.5%,而不是31%。

(参见
http://publib.boulder.ibm.com/infoce...n/r0000268.htm


当ALL

应用程序持有的TOTAL数量超过锁定列表的MAXLOCKS百分比时,会发生锁定升级。


虽然38200锁具确实存在在表xxx.xxx上只消耗了
锁定列表的48.5%,这些锁定与所有锁定相结合其他锁定系统中的
超过了60%的阈值(由MAXLOCKS设置)


因此,DB2选择具有最大行锁数的表和

将行锁升级为表锁,以释放锁定列表。


-

Matt Emmerton




" xixi" <哒**** @ yahoo.com>在消息中写道

news:c0 ************************** @ posting.google.c om ...

我们在64位窗口上使用db2 udb v8.1,此消息在db2diag.log文件中


ADM5502W升级 38200"桌子上的锁xxx.xxx锁定
意图X成功了。

目前我有locklist = 1075,maxlock = 60,所以基于公式

(((持有锁* 36)/(locklist * 4096)) * 100),我的答案是答案是31,与maxlock 60相比,我还应该有锁的空间来增长,那为什么这一点会升级呢?




在64位DB2上锁定为56个字节,而不是36个。这意味着这些38200锁定

占锁定列表的48.5%,而不是31%。

(参见
http://publib.boulder.ibm.com/infoce...n/r0000268.htm


当ALL

应用程序持有的TOTAL数量超过锁定列表的MAXLOCKS百分比时,会发生锁定升级。


虽然38200锁具确实存在在表xxx.xxx上只消耗了
锁定列表的48.5%,这些锁定与所有锁定相结合其他锁定系统中的
超过了60%的阈值(由MAXLOCKS设置)


因此,DB2选择具有最大行锁数的表和

将行锁升级为表锁,以释放锁定列表。


-

Matt Emmerton


>当ALL

应用程序持有的TOTAL数量超过锁定列表的MAXLOCKS百分比时,会发生锁定升级。
< snip>
-
Matt Emmerton



这与管理指南不同:性能表示:


"当任何一个应用程序持有的锁数达到此值时/>
百分比[在maxlocks中定义]总锁定列表大小,锁定

将对该应用程序持有的锁定进行升级。锁定
如果锁定列表空间不足,也会发生
升级。


hi, we are using db2 udb v8.1 on 64 bit windows, this message is in
the db2diag.log file

ADM5502W The escalation of "38200" locks on table "xxx.xxx" to lock
intent "X" was successful.
currently i have locklist = 1075, maxlock=60, so based on the formula

(((locks held * 36)/ (locklist *4096)) *100) , i have the answer is
31, compare with maxlock 60, i should still have space for locks to
grow, so why this point the escalation happened?

解决方案


"xixi" <da****@yahoo.com> wrote in message
news:c0**************************@posting.google.c om...

hi, we are using db2 udb v8.1 on 64 bit windows, this message is in
the db2diag.log file

ADM5502W The escalation of "38200" locks on table "xxx.xxx" to lock
intent "X" was successful.

currently i have locklist = 1075, maxlock=60, so based on the formula

(((locks held * 36)/ (locklist *4096)) *100) , i have the answer is
31, compare with maxlock 60, i should still have space for locks to
grow, so why this point the escalation happened?



Locks are 56 bytes on 64-bit DB2, not 36. This means that these 38200 locks
are consuming 48.5% of the lock list, not 31%.
(See
http://publib.boulder.ibm.com/infoce...n/r0000268.htm)

Lock escalation occurs when the TOTAL number of locks held by ALL
applications exceeds MAXLOCKS percent of the lock list.

While it is true that the 38200 locks held on table xxx.xxx only consume
48.5% of the lock list, these locks combined with all the other locks held
in the system exceeded the 60% threshold (set by MAXLOCKS)

Thus, DB2 chooses the table with the largest number of row locks and
escalates the row locks to table locks, in order to free up lock list.

--
Matt Emmerton



"xixi" <da****@yahoo.com> wrote in message
news:c0**************************@posting.google.c om...

hi, we are using db2 udb v8.1 on 64 bit windows, this message is in
the db2diag.log file

ADM5502W The escalation of "38200" locks on table "xxx.xxx" to lock
intent "X" was successful.

currently i have locklist = 1075, maxlock=60, so based on the formula

(((locks held * 36)/ (locklist *4096)) *100) , i have the answer is
31, compare with maxlock 60, i should still have space for locks to
grow, so why this point the escalation happened?



Locks are 56 bytes on 64-bit DB2, not 36. This means that these 38200 locks
are consuming 48.5% of the lock list, not 31%.
(See
http://publib.boulder.ibm.com/infoce...n/r0000268.htm)

Lock escalation occurs when the TOTAL number of locks held by ALL
applications exceeds MAXLOCKS percent of the lock list.

While it is true that the 38200 locks held on table xxx.xxx only consume
48.5% of the lock list, these locks combined with all the other locks held
in the system exceeded the 60% threshold (set by MAXLOCKS)

Thus, DB2 chooses the table with the largest number of row locks and
escalates the row locks to table locks, in order to free up lock list.

--
Matt Emmerton


> Lock escalation occurs when the TOTAL number of locks held by ALL

applications exceeds MAXLOCKS percent of the lock list.
<snip>
--
Matt Emmerton


That differs from what the Administration Guide: Performance says:

"When the number of locks held by any one application reaches this
percentage [defined in maxlocks] of the total lock list size, lock
escalation will occur for the locks held by that application. Lock
escalation also occurs if the lock list runs out of space."


这篇关于为什么锁定升级发生了的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆