• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    SQL Server误区30日谈 第2天 DBCC CHECKDB会导致阻塞

    误区 #2: DBCC CHECKDB会引起阻塞,因为这个命令默认会加锁

    这是错误的!

        在SQL Server 7.0以及之前的版本中,DBCC CHECKDB命令的本质是C语言实现的一个不断嵌套循环的代码并对表加表锁(循环嵌套算法时间复杂度是嵌套次数的N次方,作为程序员的你懂得),这种方式并不和谐,并且…..

        在SQL Server 2000时代,一个叫Steve Lindell的哥们(现在仍然在SQL Server Team)使用分析事务日志的方法来检查数据库的一致性的方式重写了DBCC CHECKDB命令。DBCC CHECKDB会阻止截断日志。当将日志从头读到尾时,在事务日志内部进行了某种Recovery操作,这实际上是另一种全新的实现Recovery的代码,但是仅限于CHECKDB命令内部。但这种方式依然存在问题,比如这个命令存在检查失败的可能性,如果检查失败,你还需要重新执行它看是否还会出现同样的错误。并且有时候,这个命令还会使用SCH_S锁,索然这个锁仅仅阻塞表扫描和表构架的改变,但通过日志来检查一致性的代码也并不是尽善尽美,并且…..

        在SQL Server 2005时代,一个叫Paul Randal的家伙(译者:也就是本文作者)再次重写了DBCC CHECKDB命令。这次使用数据库快照来检查一致性(因为数据库快照会提供在数据库某一特定时间点的一致性视图),因此不再有事务日志的分析代码,不再有任何的锁--因为访问数据库快照不需要对原数据库加任何的锁,缓冲池会自动处理可能出现的资源争用。

       

        如果想了解更多内幕消息,你可以阅读下面的文章:

        现在,在任何SQL Server版本中,如果你依然使用WITH TABLOCK提示,那将会产生表锁来保证事务的一致性。但我不推荐这种方式。因为这种方式不仅需要更长的时间,还将会尝试对数据库加排他锁,但已经活动在数据库的连接有可能导致这种方式失败。

        在SQL Server 2000中,这个命令阻止事务日志截断将会导致日志不正常增长的相关问题,但对于SQL Server 2005来说,这个命令就会导致快照相关的问题(具体请看上面的链接)。

        但是在默认情况下,自从SQL SERVER 2000之后,DBCC CHECKDB不会再产生阻塞。

    您可能感兴趣的文章:
    • SqlServer中如何解决session阻塞问题
    • mysql的udf编程之非阻塞超时重传
    • sql server 2000阻塞和死锁问题的查看与解决方法
    • 利用sys.sysprocesses检查SqlServer的阻塞和死锁
    • SQL2008中SQL应用之-阻塞(Blocking)应用分析
    • sqlserver中几种典型的等待
    • SQL语句实现查询当前数据库IO等待状况
    • SQL语句练习实例之三——平均销售等待时间
    • 系统隐形杀手——阻塞与等待(SQL)
    上一篇:SQL Server误区30日谈 第1天 正在运行的事务在服务器故障转移后继续执行
    下一篇:SQL Server误区30日谈 第3天 即时文件初始化特性可以在SQL Server中开启和关闭
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

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