SQLSERVER数据库快照的工作方式

SQLSERVER数据库快照的工作方式 翻译自：How Database Snapshots Work 最近有一个帖子《errorlog中的异常信息rolled forward 和rolled back》 里面说到： 每周六凌晨1点会出现以下信息，服务器及数据库未出现重启，节点未切换，filestream access level =0，

SQLSERVER数据库快照的工作方式

翻译自：How Database Snapshots Work

最近有一个帖子《errorlog中的异常信息rolled forward 和rolled back》

里面说到：

每周六凌晨1点会出现以下信息，服务器及数据库未出现重启，节点未切换，filestream access level =0，请各位高手帮忙解释，是什么原因导致的。

Configuration option 'user options' changed from 0 to 0. Run the RECONFIGURE statement to install.

FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

148 transactions rolled forward in database 'XX_DB' (12). This is an informational message only. No user action is required.

1 transactions rolled back in database 'XX_DB' (12). This is an informational message only. No user action is required.

Recovery completed for database XX_DB (database ID 12) in 21 second(s) (analysis 22 ms, redo 15062 ms, undo 3293 ms.) This is an informational message only. No user action is required.

为什麽会有rolled back和rolled forward？

回复者给出了下面答案：

是DBCC CHECKDB造成的，由于DBCC CHECKDB在执行时要先创建一个数据库快照，所以才会有这些提示。

这些提示并不是针对当前数据库，而是针对快照库，所以当前数据库不会有rolled forward和 rolled back。

如果还有伴有其它error信息，才可能是真的遇到问题了。

参考：

但是回复者还没有回复一个问题：

Configuration option 'user options' changed from 0 to 0. Run the RECONFIGURE statement to install.

FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'MSSQLSERVER'.

为什麽会出现FILESTREAM？？LZ说他们的系统没有使用到FILESTREAM的相关功能

今晚又看了一篇文章《》

里面说到：

正常情况下，CHECKDB/CHECKTABLE的运行不会对数据库使用排它锁，而是使用内部数据库快照(internal database snapshot)。

这个内部数据库快照实质就是Sparse Filestream, 它使用sparse file，COPY-ON-WRITE技术。详细的工作原理可以参考如下的文档：

数据库快照的工作方式
(v=SQL.105).aspx

我决定翻译一下这篇文章，看文章里是否有说到FILESTREAM

正文

数据库快照提供了一个在源数据库创建快照的时候只读的静态视图，这个静态视图会把还没有提交的事务去除掉

没有提交的事务会在新创建的数据库快照里被回滚，因为数据库引擎会在数据库快照创建完之后运行修复检查程序

但是，源数据库中的事务不会受到任何影响

数据库快照是独立于源数据库的。快照数据库会作为一个数据库存在于同一数据库服务器实例中

此外，无论什么原因，当数据库变为不可用的状态的时候，快照数据库也一样变为不可用

快照数据库不单只可以用来做报表之用，当在源数据库发生一个用户错误的时候，你可以修复源数据库到数据库快照被创建的那个时刻

自从数据库快照被创建之后，数据丢失仅仅限于快照创建之后的那些数据库数据更新的丢失

而且，创建数据库快照对于在一个大的数据库更新操作之前特别有用，例如改变数据库的架构或者表结构

对于更多数据库快照的用途，大家可以看一下数据库快照的典型应用

理解数据库快照的工作方式是很有帮助的，虽然不一定要使用数据库快照。数据库快照操作的级别是“页面级别”

在源数据库的一个页面被第一次修改之前，源数据页面会从源数据库复制到数据库快照。这个过程叫做：“COPY-ON-WRITE”操作

数据库快照存储了源数据页面，保留当快照被创建时已经存在的数据记录。后来的数据页面修改不会影响到快照里的页面内容。

对于每一个第一次被修改的页面会重复上面的COPY-ON-WRITE操作。用这种方法，快照会保存保留了所有已经被修改的数据记录的原始页面

当快照被创建的时候。

为了存储这些复制的原始页面，快照使用一个或者多个稀疏文件。最初，一个稀疏文件实际上是一个没有用户数据和还没有分配磁盘空间的空白的文件

当源数据库里越来越多的数据页面被更新，数据文件的size会增长。当快照建立之后，稀疏文件只会占用一点磁盘空间，当源数据库不断更新，

一个稀疏文件会增长成为一个大文件

想知道稀疏文件的更多信息，可以参阅：Understanding Sparse File Sizes in Database Snapshots

下面的图片描述了一个"copy-on-write"操作。在下面的快照图里灰白色的方块表示一个稀疏文件里还没有被分配的空间

当接收到第一个源数据库的第一个数据页面更新，数据库引擎会将页面写入到稀疏文件，并且操作系统会在快照的稀疏文件里分配

空间然后复制原始数据页。然后数据库引擎会更新源数据库的数据页面。

注意：因为数据库快照不是数据库存储冗余，快照不会防止磁盘错误或者其他类型的数据库损坏。如果你必须还原源数据库到某一个

时间点，这个时间点是数据库快照创建的时刻，那么你就要执行一个备份策略，从数据库备份中还原，而不是从数据库快照中还原

数据库快照的读操作

对于用户来讲，数据库快照从来不会发生改变，因为在数据库快照上的读操作总是访问原始数据页面无论这些数据页面来自哪里

如果在源数据库的数据页面从来没有被更新过，快照上的读操作会读取源数据库的源数据页面。下面的图片显示了一个在刚刚新建的快照上

的读操作，对应的稀疏文件并没有包含任何数据页面。这个读操作只会读取源数据库的数据

当有一个数据页面被更新之后，快照上的读操作就会访问存储在稀疏文件里原始数据页面，下面的图片描述了一个快照上的读操作

访问一个在源数据库被更新了的数据页面。读操作读取快照稀疏文件里的原始页面。

数据库快照增长对于更新模式的影响

如果你的源数据库相当大并且你正在关注磁盘空间的使用率，在某一时刻你应该用新的数据库快照替换旧的快照。

理想的数据库快照生存期依据于快照的增长速率和磁盘的可用空间。所需的磁盘空间取决于快照期间源数据库有多少的数据页面被更新了

因此，如果大部分的更新只是一小部分页面的重复更新，快照增长速率会比较慢，快照所需空间也会保持相对比较小的空间

相反，当所有原始页面至少最终被更新，快照会增长到与源数据库大小一样。如果磁盘开始填满，快照和磁盘会进行相互竞争对于磁盘空间

如果磁盘已经没有空间，对于快照的写操作会失败

记录：关于实际和潜在的快照大小的更多信息可以参阅：Understanding Sparse File Sizes in Database Snapshots

因此，当计划要多少磁盘空间在快照期间知道典型的数据库更新模式是很有用的。对于某些数据库，更新的频率是固定的，

例如：一个库存数据库有可能有很多每日都需要更新的页面，每日或每个星期替换旧的数据库快照是很有用的。对于其他数据库，

页面更新的比例有可能有很大的不同在业务运作期间；例如，一个目录数据库有可能只在季度更新，在其他时间只会偶尔更新

在季度的交替前和后创建数据库快照是一种业务策略。季度交替前的数据库快照允许修复重要的更新错误

而季度交替后的快照能够被用来做报表写入一直到下一个季度

下面的图片描述了两种更新模式的数据库快照的size的影响。

更新模式A影响只有30%原始页面被更新的快照环境

更新模式B影响80%原始页面被更新的快照环境

数据库快照的元数据

对于数据库快照，数据库元数据包括源数据库ID属性，ID属性存储在sys.databases目录视图里的某一列里

更多关于ID属性的信息，，可以查看sys.databases (Transact-SQL).

通常，一个数据库快照不会显示元数据信息（就是说你查不到快照数据库里面的一些元数据），不过你可以从源数据库那里查询这些元数据。

这些元数据包括，下面的SQL语句返回的数据

database_snapshotsys.database_files