誤區 #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不會再產生阻塞。
