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

這是錯誤的！

在SQL Server 7.0以及之前的版本中，DBCC CHECKDB命令的本質(zhì)是C語言實(shí)現(xiàn)的一個(gè)不斷嵌套循環(huán)的代碼并對表加表鎖(循環(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會阻止截?cái)嗳罩尽．?dāng)將日志從頭讀到尾時(shí)，在事務(wù)日志內(nèi)部進(jìn)行了某種Recovery操作，這實(shí)際上是另一種全新的實(shí)現(xiàn)Recovery的代碼，但是僅限于CHECKDB命令內(nèi)部。但這種方式依然存在問題，比如這個(gè)命令存在檢查失敗的可能性，如果檢查失敗，你還需要重新執(zhí)行它看是否還會出現(xiàn)同樣的錯誤。并且有時(shí)候，這個(gè)命令還會使用SCH_S鎖，索然這個(gè)鎖僅僅阻塞表掃描和表構(gòu)架的改變，但通過日志來檢查一致性的代碼也并不是盡善盡美，并且…..

在SQL Server 2005時(shí)代，一個(gè)叫Paul Randal的家伙（譯者：也就是本文作者）再次重寫了DBCC CHECKDB命令。這次使用數(shù)據(jù)庫快照來檢查一致性（因?yàn)閿?shù)據(jù)庫快照會提供在數(shù)據(jù)庫某一特定時(shí)間點(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í)間，還將會嘗試對數(shù)據(jù)庫加排他鎖，但已經(jīng)活動在數(shù)據(jù)庫的連接有可能導(dǎo)致這種方式失敗。

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

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

版權(quán)聲明：本站文章來源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。