如何大幅提高DBCC CHECKDB/DBCC CHECKTABLE的性能

隨著時間的推移，數據庫變的越來越大，幾百個GB甚至幾個TB大小的數據庫越來越多。為了檢查數據庫的完整性，定期運行DBCC CHECKDB/CHECKTABLE是最佳實踐。但是隨著數據庫的增大，如何縮短DBCC CHECKDB/CHECKTABLE的運行時間是DBA常常需要面對的一個挑戰。本短

隨著時間的推移，變的越來越大，幾百個gb甚至幾個tb大小的越來越多。為了檢查數據庫的完整性，定期運行dbcc checkdb/checktable是最佳實踐。但是隨著數據庫的增大，如何縮短dbcc? checkdb/checktable的運行時間是dba常常需要面對的一個挑戰。本短文介紹一些方法，可以大幅縮短常規checkdb/checktale 的運行時間。

正常情況下，CHECKDB/CHECKTABLE的運行不會對數據庫使用排它鎖，而是使用內部數據庫快照(internal database snapshot)。 這個內部數據庫快照實質就是Sparse Filestream, 它使用sparse file，COPY-ON-WRITE技術。詳細的工作原理可以參考如下的文檔：

數據庫快照的工作方式

簡單說，對數據庫快照的讀操作如下圖所示：

如果你想觀察DBCC CHECKDB/CHECKTABLE運行時的快照，你可以使用streams.exe工具。我使用它觀測到如下的結果：

上圖中的 “MSSQL_DBCC10:$DATA”就是附加在testdb.mdf后面的Sparse Filestream。后面的那串數字是數據庫加上stream的總的大小，這個和下面的語句觀察到的size_on_disk_bytes是一致的：

select * from? sys.dm_io_virtual_file_stats(5,1)

?

但是要注意到，因為sparse filestream并不實際占有磁盤大小，上面的大小只是一個空間的保留，并不是磁盤上真的有這么多的數據存在，并不真正占有磁盤的這么大的空間。

言歸正傳，上面介紹的internal snapshot （也就是sparse filestream）有什么關系呢？

先做個實驗，運行CHECKDB幾次看看運行時間：

DBCC CHECKDB(TESTDB)

這個運行了大概50秒的時間。然后我使用TABLOCK選項測試幾次：

DBCC CHECKDB(TESTDB)

withTABLOCK

天啊，它只需要大概5秒的時間就跑完了，整整快了10倍！讀到這里，你知道了第一個大幅縮短CHECKDB/CHECKTABLE的辦法，就是使用TABLOCK。這個hint 告訴SQL server 使用鎖來進行檢查，但也影響了數據庫用戶的使用。比如在檢查某個table 的時候，就可能無法對這個table進行修改。 那么有沒有更好的不影響用戶的辦法呢？有的，就是使用snapshot 數據庫。

首先建立一個snapshot 數據庫：

createdatabase myTESTDB_snapshot

on

( name =TESTDB_Data ,filename=‘C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATATESTDB_Data.ss’)

asSNAPSHOTOF TESTDB

然后對這個snapshot數據庫進行CHECKDB：

DBCC CHECKDB(myTESTDB_snapshot)

結果令人驚訝，它也僅僅使用了5秒，和使用TABLOCK一樣的性能！ 太令人興奮了，不影響用戶的情況下比原來的CHECKDB快了10倍。你發現了什么問題嗎？恩，對，我是對myTESTDB_snapshot進行CHECKDB，而不是TESTDB。這樣可以么？可以的， 原因自己思考。可以參考snapshot的工作原理來考慮。

那么對CHECKTABLE有什么不一樣么？ 我測試的結果類似。 就是說， 使用snapshot 數據庫來進行CHECKTABLE的性能和使用TABLOCK的性能類似，都能大幅縮短檢查的時間。測試的結果如下：