誤區(qū) #2: DBCC CHECKDB會引起阻塞，因?yàn)檫@個命令默認(rèn)會加鎖

這是錯誤的！

    在SQL Server 7.0以及之前的版本中，DBCC CHECKDB命令的本質(zhì)是C語言實(shí)現(xiàn)的一個不斷嵌套循環(huán)的代碼并對表加表鎖(循環(huán)嵌套算法時間復(fù)雜度是嵌套次數(shù)的N次方,作為程序員的你懂得),這種方式并不和諧,并且…..

    在SQL Server 2000時代，一個叫Steve Lindell的哥們（現(xiàn)在仍然在SQL Server Team）使用分析事務(wù)日志的方法來檢查數(shù)據(jù)庫的一致性的方式重寫了DBCC CHECKDB命令。DBCC CHECKDB會阻止截斷日志。當(dāng)將日志從頭讀到尾時，在事務(wù)日志內(nèi)部進(jìn)行了某種Recovery操作，這實(shí)際上是另一種全新的實(shí)現(xiàn)Recovery的代碼，但是僅限于CHECKDB命令內(nèi)部。但這種方式依然存在問題，比如這個命令存在檢查失敗的可能性，如果檢查失敗，你還需要重新執(zhí)行它看是否還會出現(xiàn)同樣的錯誤。并且有時候，這個命令還會使用SCH_S鎖，索然這個鎖僅僅阻塞表掃描和表構(gòu)架的改變，但通過日志來檢查一致性的代碼也并不是盡善盡美，并且…..

    在SQL Server 2005時代，一個叫Paul Randal的家伙（譯者：也就是本文作者）再次重寫了DBCC CHECKDB命令。這次使用數(shù)據(jù)庫快照來檢查一致性（因?yàn)閿?shù)據(jù)庫快照會提供在數(shù)據(jù)庫某一特定時間點(diǎn)的一致性視圖）,因此不再有事務(wù)日志的分析代碼，不再有任何的鎖--因?yàn)樵L問數(shù)據(jù)庫快照不需要對原數(shù)據(jù)庫加任何的鎖，緩沖池會自動處理可能出現(xiàn)的資源爭用。

    如果想了解更多內(nèi)幕消息，你可以閱讀下面的文章:

• 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

    現(xiàn)在，在任何SQL Server版本中,如果你依然使用WITH TABLOCK提示，那將會產(chǎn)生表鎖來保證事務(wù)的一致性。但我不推薦這種方式。因?yàn)檫@種方式不僅需要更長的時間，還將會嘗試對數(shù)據(jù)庫加排他鎖，但已經(jīng)活動在數(shù)據(jù)庫的連接有可能導(dǎo)致這種方式失敗。

    在SQL Server 2000中，這個命令阻止事務(wù)日志截斷將會導(dǎo)致日志不正常增長的相關(guān)問題，但對于SQL Server 2005來說，這個命令就會導(dǎo)致快照相關(guān)的問題（具體請看上面的鏈接）。

    但是在默認(rèn)情況下,自從SQL SERVER 2000之后，DBCC CHECKDB不會再產(chǎn)生阻塞。