如何大幅提高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 数据库：

AI Content Detector

Writer推出的AI内容检测工具

119

查看详情

createdatabase myTESTDB_snapshot

on

( name =TESTDB_Data ,filename='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\TESTDB_Data.ss')

asSNAPSHOTOF TESTDB

然后对这个snapshot数据库进行CHECKDB：

DBCC CHECKDB(myTESTDB_snapshot)

结果令人惊讶，它也仅仅使用了5秒，和使用TABLOCK一样的性能！ 太令人兴奋了，不影响用户的情况下比原来的CHECKDB快了10倍。你发现了什么问题吗？恩，对，我是对myTESTDB_snapshot进行CHECKDB，而不是TESTDB。这样可以么？可以的， 原因自己思考。可以参考snapshot的工作原理来考虑。

那么对CHECKTABLE有什么不一样么？ 我测试的结果类似。 就是说， 使用snapshot 数据库来进行CHECKTABLE的性能和使用TABLOCK的性能类似，都能大幅缩短检查的时间。测试的结果如下：