SQL Server误区30日谈-Day23-有关锁升级的误区-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

SQL Server误区30日谈-Day23-有关锁升级的误区

简介:
 本系列文章是我在sqlskill.com的PAUL的博客看到的,很多误区都比较具有典型性和代表性,原文来自T-SQL Tuesday #11: Misconceptions about.... EVERYTHING!!,经过我们团队的翻译和整理发布在AgileSharp上。希望对大家有所帮助。

 

误区 #23: 锁升级的过程是由行锁升级到页锁,再由页锁升级到表锁

错误

    实际不是,在SQL Server 2005和之前的版本,锁升级会直接升到表锁。

    在SQL Server 2005或SQL Server 2008,你可以通过如下跟踪标志改变锁升级的行为:

    标志1211-完全禁止锁升级,但锁使用的内存会被限制在动态分配内存的60%,当超过这个值时,更多的锁将会伴随着内存溢出错误而失败。
    标志1224-禁止锁升级,但内存使用超过40%时,会自动开启锁升级
    如果标志1211和1224跟踪标志同时被设置了,只有标志1211会生效。更详细的内容请看Books Online。

 

    在SQL Server 2008中,还可以以表为单位进行锁行为的设置,可以通过ALTER TABLE blah SET (LOCK_ESCALATION = XXX),在这个命令中XXX所代表的是下面几项中的一项:

TABLE: 直接从行锁升级到表锁。

AUTO:如果存在表分区,则升级为分区锁,但不会进一步升级。

DISABLE:禁用锁升级,这并不意味着禁用表锁,就像BOL(Books Online entry)中所说,在序列化隔离等级的条件下进行表扫描等操作时还需要表锁。

 

    在2008年1月的时候,我写了一篇包含分区锁例子的博文,请看:SQL Server 2008: Partition-level lock escalation details and examples。

    或许你会想为什么LOCK_ESCALATION = XXX设置中AUTO不是默认值,这时因为早期测试中某些人发现这个选项更容易引起死锁。就像对于上述两个有关锁的跟踪标记一样,对于这个选项设置为AUTO也同样需要谨慎。

分类: SQL Server DBA误区



本文转自CareySon博客园博客,原文链接http://www.cnblogs.com/CareySon/archive/2013/01/17/2863986.html如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章