SQL Server誤區30日談 第2天 DBCC CHECKDB會招致壅塞。本站提示廣大學習愛好者：（SQL Server誤區30日談 第2天 DBCC CHECKDB會招致壅塞）文章只能為提供參考，不一定能成為您想要的結果。以下是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不會再發生壅塞。
