误区 #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命令。这次使用数据库快照来检查一致性（因为数据库快照会提供在数据库某一特定时间点的一致性视图）,因此不再有事务日志的分析代码，不再有任何的锁–因为访问数据库快照不需要对原数据库加任何的锁，缓冲池会自动处理可能出现的资源争用。
如果想了解更多内幕消息，你可以阅读下面的文章:
-
checkdb from every angle: complete description of all checkdb stages
-
checkdb from every angle: why would checkdb run out of space?
-
database snapshots – when things go wrong
-
issues around dbcc checkdb and the use of hidden database snapshots
-
do transactions rollback when dbcc checkdb runs?
-
diskeeper 10 intelliwrite corruption bug
现在，在任何sql server版本中,如果你依然使用with tablock提示，那将会产生表锁来保证事务的一致性。但我不推荐这种方式。因为这种方式不仅需要更长的时间，还将会尝试对数据库加排他锁，但已经活动在数据库的连接有可能导致这种方式失败。
在sql server 2000中，这个命令阻止事务日志截断将会导致日志不正常增长的相关问题，但对于sql server 2005来说，这个命令就会导致快照相关的问题（具体请看上面的链接）。
但是在默认情况下,自从sql server 2000之后，dbcc checkdb不会再产生阻塞。