SQL Server误区30日谈 第23天 有关锁升级的误区_MsSql

误区 #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也同样需要谨慎。

时间: 2024-10-25 20:15:54

SQL Server误区30日谈 第23天 有关锁升级的误区_MsSql的相关文章

SQL Server误区30日谈 第23天 有关锁升级的误区

误区 #23: 锁升级的过程是由行锁升级到页锁,再由页锁升级到表锁 错误     实际不是,在SQL Server 2005和之前的版本,页锁会直接升级到表锁.     在SQL Server 2005或SQL Server 2008,你可以通过如下跟踪标志改变锁升级的行为: 标志1211-完全禁止锁升级,但锁使用的内存会被限制在动态分配内存的60%,当超过这个值时,更多的锁将会伴随着内存溢出错误而失败. 标志1224-禁止锁升级,但内存使用超过40%时,会自动开启锁升级     如果标志121

SQL Server误区30日谈 第25天 有关填充因子的误区_MsSql

误区 #25:多个有关填充因子的误区    都是错误的 25a) 填充因子是一直存在的    不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话):重要: 填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致.如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义.因为这时页即使不满也需要进行分页. 25 b)填充因子0和100是不同的    错误,由BOL的一句话可以看到    填充因子0

SQL Server误区30日谈 第17天 有关页校验和的误区_MsSql

其实我之前已经有文章详细解释了页校验和:How to tell if the IO subsystem is causing corruptions? 误区 #17:几个有关页校验和的误区 坊间流传的基本是错误的   17 a)页校验和(Page CheckSum)在从SQL Server 2000或7.0升级上来之后自动开启     其实不是,从旧的实例升级上来的数据库不会自动开启页校验和,除非你显式使用ALTER DATABASE databasename SET PAGE_VERIFY C

SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞_MsSql

误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁 这是错误的!     在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且-..     在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重

SQL Server误区30日谈 第16天 数据的损坏和修复_MsSql

误区 #16:多个关于数据的损坏和修复误区 坊间流传的很多版本都不正确 我已经听过很多关于数据修复可以做什么.不可以做什么.什么会导致数据损坏以及损坏是否可以自行消失.其实我已经针对这类问题写过多篇博文,因此本篇博文可以作为"流言终结者"来做一个总结,希望你能有收获.   首先,对于数据修复可以做什么,不可以做什么,我已经写过一篇博文Misconceptions around database repair涵盖了13个误区-从不用DBCC CHECKDB是否能修复错误(当然不能)到RE

SQL Server误区30日谈 第29天 有关堆碎片的误区

误区 #29:可以通过对堆建聚集索引再DROP后进行堆上的碎片整理 Nooooooooooooo!!! 对堆建聚集索引再DROP在我看来是除了收缩数据库之外最2的事了.      如果你通过sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片,绝对不要通过建立聚集索引再删除聚集索引来整理堆碎片.好的做法应该是建立聚集索引之后不再删除,已经有非常多的资料阐述如何选择一个理想的聚集索引键--窄,很少变动,唯一,自增.Kimberly

SQL Server误区30日谈 第25天 有关填充因子的误区

误区 #25:多个有关填充因子的误区     都是错误的 25a) 填充因子是一直存在的     不是的,通过Books Online可以看到(译者:我在新版的BOL没有找到这句话): 重要: 填充因子仅仅在索引创建或重建时生效,SQL Server存储引擎并不会一直保证页内的空闲值和填充因子保持一致.如果为了保证页内的空余值和指定的填充因子保持一直那么填充因子就会失去意义.因为这时页即使不满也需要进行分页. 25 b)填充因子0和100是不同的     错误,由BOL的一句话可以看到     

SQL Server误区30日谈 第17天 有关页校验和的误区

其实我之前已经有文章详细解释了页校验和:How to tell if the IO subsystem is causing corruptions? 误区 #17:几个有关页校验和的误区 坊间流传的基本是错误的 17 a)页校验和(Page CheckSum)在从SQL Server 2000或7.0升级上来之后自动开启 其实不是,从旧的实例升级上来的数据库不会自动开启页校验和,除非你显式使用ALTER DATABASE databasename SET PAGE_VERIFY CHECKSU

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢