SQL Server 灾难恢复31天之第1天：DBCC CHECK命令会自动使用已经存在的数据库快照吗？

说明：灾难恢复系列的文章是由 Robert Davis 写的，发布在SQLSoldier， 个人认为挺不错的，所以根据自己的理解，边测试边整理，并非直接翻译，如有不准确，欢迎指正。

 

作为灾难恢复这个系列的第一篇文章，我们看一下如果一个数据库存在快照数据库，那么当执行DBCC CHECK命令时，是否会自动使用已存在的快照数据库呢？我一直认为是不会的，并且也这样告诉其它人。为了证明给我自己以及其它人，本篇将尝试最终去证明DBCC CHECK命令将不会使用已存在的数据库快照。

执行DBCC CHECK命令时是否会自动使用已存在的快照数据库 ?

我做了大量DBCC CHECK命令的调查试图找到办法查看DBCC CHECK命令是否有隐示的创建和使用数据库快照，最终发现快照没有显示在sys.databases, sys.master_file以及其它的系统目录中，另外，数据库快照的创建不会触发服务器级别的事件也不会触发库级别的事件以及SQL跟踪和扩展事件。

最终，我发现通过扩展示件的databases_dbcc_logical_scan事件可以看到它，这个事件会返回当前正针对某个数据库运行的数据库的ID以及实际正在哪个数据库上操作的数据库ID，当前实际操作的数据库是一个隐藏的数据为快照，它的database_id不会显示在sys.databases,而且DB_NAME()函数会返回它的源数据库的名称，我设置了一个扩展事件会话来收集databases_dbcc_logical_scan事件，它含有database_id和database_name列。我使用ring buffer target因为我并不打算保留任何数据，执行下面的脚本，它暂时还未激活。

CREATE EVENT SESSION [TestSnap] ON SERVER 
ADD EVENT sqlserver.databases_dbcc_logical_scan(
    ACTION(sqlserver.database_id,
        sqlserver.database_name)) 
ADD TARGET package0.ring_buffer
WITH (MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB);

然后为AdventureWorks2012数据库创建一个快照库AWSnap，这样我们就有了一个已存在的数据库和它的快照库。

CREATE DATABASE AWSnap
    ON (NAME = N'AdventureWorks2012_Data',
        FILENAME = N'D:\SQL2012\SNP\AdventureWorks2012_Data.ndf')
        AS SNAPSHOT OF AdventureWorks2012;

现在启用扩展事件会话，如下图点击Start Session，然后再点击Watch Live Data，这样当对AdventureWorks2012数据库运行DBCC CHECKDB时就能实时看到事件内容，接下来我们打开一个查询窗口运行DBCC CHECKDB。

从下图中我们可以看到每一个记录中，database_id和database_id(action)都是不同的，如果你查询sys.databases那么没有database_id(action)的ID记录，如果我们用DB_NAME(7)查数据库名称，当DBCC CHECKDB正在运行时，它返回AdventureWorks2012，当DBCC CHECKDB运行完后，它返回NULL.

接下来我们做另一个测试，先关掉刚才的Live Data 窗口并重新打开一个新的，以保证全部清空记录，再对AWSnap库运行DBCC CHECKDB，我们可以看到database_id和database_id(action)现在是相同的值，如果查询sys.databases能够看到它的值对应到数据库AWSnap.
 

总结：
正如你所看到的那样，如果你想让DBCC CHECKDB使用已存在的数据库快照，需要特别指定快照数据库，否则DBCC CHECKDB不会自动检测并使用已存在的快照数据库。

SQL Server 灾难恢复31天之第2天：包含数据库备份在还原时的保护