SQLServer的误区30天谈第二天DBCCCHECKDB将导致肠梗阻

误区2：# DBCC CHECKDB造成堵塞，因为命令将被默认

这个错了。

在SQL Server 7或更早的版本，CHECKDB命令基本上是DBCC C语言与表锁实现连续循环嵌套代码和表格（嵌套循环算法的时间复杂度是多少嵌套N，作为一个程序员，你知道的），这种方法是不和谐的，和…

在SQL Server 2000的时代，一个名为Steve Lindell的SQL（服务器）还用分析事务日志检查数据库一致性的方式，改写DBCC CHECKDB command.dbcc会阻止日志截断。当日志从头读到尾，恢复操作都是在事务日志，这实际上是另一个新的代码来实现复苏，但这仅限于CHECKDB命令。但是，仍然有问题，在这种方式中，例如，有失败可能性的命令。如果检查失败，需要重新执行它是否会再次出现同样的错误。有时候，这个命令将使用sch_s锁，锁断堵只扫描表和表结构的变化，但通过日志来检查代码的一致性是不完美的，和…

在SQL Server 2005的时代，一个叫Paul Randal的家伙改写了DBCC CHECKDB命令。一个数据库快照的一致性检查的使用（因为数据库快照将在特定的时间点提供一个一致的数据库视图），所以没有更多的事务日志分析代码，不再有任何因为没有任何数据库锁锁需要访问数据库的快照，缓冲池将自动处理可能发生的资源争用。
如果您想了解更多关于内部信息的信息，您可以阅读下面的文章：
从每一个角度都会：CHECKDB阶段完整的描述
从各个角度CHECKDB：为什么CHECKDB运行的空间
数据库快照-当事情出错时
问题在DBCC CHECKDB和隐藏的数据库快照的使用
做交易的时候，DBCC CHECKDB运行回滚
Diskeeper 10 intelliwrite腐败漏洞

现在，在任何SQL Server版本，如果你还在使用WITH TABLOCK提示，它会产生一个表锁来保证交易的一致性。但我不推荐这个，因为这样不仅会花更长的时间，但也要加锁的数据库，而是连接在数据库活动可能导致失败。

在SQL Server 2000中，此命令防止事务日志截断导致日志异常增长。但是对于SQL Server 2005，此命令会导致与快照相关的问题。

但是，默认情况下，在SQL Server 2000中，DBCC CHECKDB不会堵塞。