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

這是錯(cuò)誤的！

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

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

    在SQL Server 2005時(shí)代，一個(gè)叫Paul Randal的家伙（譯者：也就是本文作者）再次重寫了DBCC CHECKDB命令。這次使用數(shù)據(jù)庫快照來檢查一致性（因?yàn)閿?shù)據(jù)庫快照會(huì)提供在數(shù)據(jù)庫某一特定時(shí)間點(diǎn)的一致性視圖）,因此不再有事務(wù)日志的分析代碼，不再有任何的鎖--因?yàn)樵L問數(shù)據(jù)庫快照不需要對(duì)原數(shù)據(jù)庫加任何的鎖，緩沖池會(huì)自動(dòng)處理可能出現(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提示，那將會(huì)產(chǎn)生表鎖來保證事務(wù)的一致性。但我不推薦這種方式。因?yàn)檫@種方式不僅需要更長的時(shí)間，還將會(huì)嘗試對(duì)數(shù)據(jù)庫加排他鎖，但已經(jīng)活動(dòng)在數(shù)據(jù)庫的連接有可能導(dǎo)致這種方式失敗。

    在SQL Server 2000中，這個(gè)命令阻止事務(wù)日志截?cái)鄬?huì)導(dǎo)致日志不正常增長的相關(guān)問題，但對(duì)于SQL Server 2005來說，這個(gè)命令就會(huì)導(dǎo)致快照相關(guān)的問題（具體請(qǐng)看上面的鏈接）。

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