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命令。這次使用資料庫快照集來檢查一致性（因為資料庫快照集會提供在資料庫某一特定時間點的一致性視圖）,因此不再有交易記錄的分析代碼，不再有任何的鎖--因為訪問資料庫快照集不需要對原資料庫加任何的鎖，緩衝池會自動處理可能出現的資源爭用。

如果想瞭解更多內幕訊息，你可以閱讀下面的文章:

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