隨著時間的推移,數(shù)據(jù)庫變的越來越大,幾百個GB甚至幾個TB大小的數(shù)據(jù)庫越來越多。為了檢查數(shù)據(jù)庫的完整性,定期運(yùn)行DBCC CHECKDB/CHECKTABLE是最佳實踐。但是隨著數(shù)據(jù)庫的增大,如何縮短DBCC CHECKDB/CHECKTABLE的運(yùn)行時間是DBA常常需要面對的一個挑戰(zhàn)。本短
隨著時間的推移,變的越來越大,幾百個GB甚至幾個TB大小的越來越多。為了檢查數(shù)據(jù)庫的完整性,定期運(yùn)行DBCC CHECKDB/CHECKTABLE是最佳實踐。但是隨著數(shù)據(jù)庫的增大,如何縮短DBCC CHECKDB/CHECKTABLE的運(yùn)行時間是DBA常常需要面對的一個挑戰(zhàn)。本短文介紹一些方法,可以大幅縮短常規(guī)CHECKDB/CHECKTALE 的運(yùn)行時間。
正常情況下,CHECKDB/CHECKTABLE的運(yùn)行不會對數(shù)據(jù)庫使用排它鎖,而是使用內(nèi)部數(shù)據(jù)庫快照(internal database snapshot)。 這個內(nèi)部數(shù)據(jù)庫快照實質(zhì)就是Sparse Filestream, 它使用sparse file,COPY-ON-WRITE技術(shù)。詳細(xì)的工作原理可以參考如下的文檔:
數(shù)據(jù)庫快照的工作方式
簡單說,對數(shù)據(jù)庫快照的讀操作如下圖所示:
如果你想觀察DBCC CHECKDB/CHECKTABLE運(yùn)行時的快照,你可以使用streams.exe工具。我使用它觀測到如下的結(jié)果:
上圖中的 “MSSQL_DBCC10:$DATA”就是附加在testdb.mdf后面的Sparse Filestream。后面的那串?dāng)?shù)字是數(shù)據(jù)庫加上stream的總的大小,這個和下面的語句觀察到的size_on_disk_bytes是一致的:
select * from sys.dm_io_virtual_file_stats(5,1)
但是要注意到,因為sparse filestream并不實際占有磁盤大小,上面的大小只是一個空間的保留,并不是磁盤上真的有這么多的數(shù)據(jù)存在,并不真正占有磁盤的這么大的空間。
言歸正傳,上面介紹的internal snapshot (也就是sparse filestream)有什么關(guān)系呢?
先做個實驗,運(yùn)行CHECKDB幾次看看運(yùn)行時間:
DBCC CHECKDB(TESTDB)
這個運(yùn)行了大概50秒的時間。然后我使用TABLOCK選項測試幾次:
DBCC CHECKDB(TESTDB)
withTABLOCK
天啊,它只需要大概5秒的時間就跑完了,整整快了10倍!讀到這里,你知道了第一個大幅縮短CHECKDB/CHECKTABLE的辦法,就是使用TABLOCK。這個hint 告訴SQL server 使用鎖來進(jìn)行檢查,但也影響了數(shù)據(jù)庫用戶的使用。比如在檢查某個table 的時候,就可能無法對這個table進(jìn)行修改。 那么有沒有更好的不影響用戶的辦法呢?有的,就是使用snapshot 數(shù)據(jù)庫。
首先建立一個snapshot 數(shù)據(jù)庫:
createdatabase myTESTDB_snapshot
on
( name =TESTDB_Data ,filename='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\TESTDB_Data.ss')
asSNAPSHOTOF TESTDB
然后對這個snapshot數(shù)據(jù)庫進(jìn)行CHECKDB:
DBCC CHECKDB(myTESTDB_snapshot)
結(jié)果令人驚訝,它也僅僅使用了5秒,和使用TABLOCK一樣的性能! 太令人興奮了,不影響用戶的情況下比原來的CHECKDB快了10倍。你發(fā)現(xiàn)了什么問題嗎?恩,對,我是對myTESTDB_snapshot進(jìn)行CHECKDB,而不是TESTDB。這樣可以么?可以的, 原因自己思考。可以參考snapshot的工作原理來考慮。
那么對CHECKTABLE有什么不一樣么? 我測試的結(jié)果類似。 就是說, 使用snapshot 數(shù)據(jù)庫來進(jìn)行CHECKTABLE的性能和使用TABLOCK的性能類似,都能大幅縮短檢查的時間。測試的結(jié)果如下:
DBCC CHECKDB |
40-50 seconds |
DBCC CHECKDB with TABLOCK |
5 seconds |
DBCC CHECKDB on snapshot database |
5 seconds |
DBCC CHECKTABLE Batch |
8-12 minutes |
DBCC CHECKTABLE Batch with TABLOCK |
18 seconds |
DBCC CHECKTABLE Batch on Snapshot database |
20 seconds |
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com