最近,开发系统使用SqlServer2008 R2,但是由于系统数据压力的增加,准备增加一个和正式数据库同步的库,用来供接口和报表使用,所以开始对SqlServer里面的一些技术开始研究,第一篇先来研究一下最基本的数据库快照。
基本概念
先简单介绍一下快照的基本概念,数据库快照是 SQL Server 数据库(源数据库)的只读静态视图。 自创建快照那刻起,数据库快照在事务上与源数据库一致。 数据库快照始终与其源数据库位于同一服务器实例上。 当源数据库更新时,数据库快照也将更新。 因此,数据库快照存在的时间越长,就越有可能用完其可用磁盘空间。
数据库快照操作的级别是“页面级别”,在第一次修改源数据库页之前,先将原始页从源数据库复制到快照, 快照将存储原始页,保留它们在创建快照时的数据记录。 对要进行第一次修改的每一页重复此过程。 对于用户而言,数据库快照似乎始终保持不变,因为对数据库快照的读操作始终访问原始数据页,而与页驻留的位置无关。其实就是快照一直会备份源数据的修改之前的原始页,所以随着数据的修改增多,快照的文件存储就会慢慢变大。
为了存储复制的原始页,快照使用一个或多个“稀疏文件”。 最初,稀疏文件实质上是空文件,不包含用户数据并且未被分配存储用户数据的磁盘空间。 随着源数据库中更新的页越来越多,文件的大小也不断增长。 下图说明了两种相对的更新模式对快照大小的影响。 更新模式 A 反映的是在快照使用期限内仅有 30% 的原始页更新的环境。 更新模式 B 反映的是在快照使用期限内有 80% 的原始页更新的环境。
快照可用于报告目的。
客户端可以查询数据库快照,这对于基于创建快照时的数据编写报表是很有用的。
使数据免受管理失误所带来的影响。
如果源数据库上出现用户错误,您可将源数据库恢复到创建给定数据库快照时的状态。 丢失的数据仅限于创建该快照后数据库中发生更新的数据。
例如,在进行重大更新(比如大容量更新或架构更改)前,对数据库创建数据库快照以保护数据。 一旦进行了错误操作,可以使用快照将数据库恢复到生成快照时的状态。 为此目的进行的。
使数据免受用户失误所带来的影响。
定期创建数据库快照,可以减轻重大用户错误(例如,删除的表)的影响。 为了很好地保护数据,可以创建时间跨度足以识别和处理大多数用户错误的一系列数据库快照。 例如,根据磁盘资源,可以每 24 小时创建 6 到 12 个滚动快照。 每创建一个新的快照,就删除最早的快照。
若要从用户错误中恢复,可以将数据库恢复到在错误发生的前一时刻的快照。 为此目的进行的恢复很可能比从备份还原快得多;但是,此后您无法对数据进行前滚操作。
或者,也可以利用快照中的信息,手动重新创建删除的表或其他丢失的数据。 例如,可以将快照中的数据大容量复制到数据库中,然后手动将数据合并回数据库中。
管理测试数据库。
在测试环境中,当每一轮测试开始时针对要包含相同数据的数据库重复运行测试协议将十分有用。 在运行第一轮测试前,应用程序开发人员或测试人员可以在测试数据库中创建数据库快照。 每次运行测试之后,数据库都可以通过恢复数据库快照快速返回到它以前的状态。
数据库快照的限制
源数据库的限制:
不能对数据库进行删除、分离或还原。可以备份源数据库,这方面将不受数据库快照的影响。
源数据库的性能受到影响。由于每次更新页时都会对快照执行“写入时复制”操作,导致源数据库上的 I/O 增加。
不能从源数据库或任何快照中删除文件。
快照数据库的限制:
数据库快照必须与源数据库在相同的服务器实例上创建和保留。
始终对整个数据库制作数据库快照。
当将源数据库中更新的页强制压入快照时,如果快照用尽磁盘空间或者遇到其他错误,则该快照将成为可疑快照并且必须将其删除。
快照为只读。
禁止对 model 数据库、master 数据库和 tempdb 数据库创建快照。
不能在 FAT32 文件系统或 RAW 分区上创建数据库快照。 数据库快照所用的稀疏文件由 NTFS 文件系统提供。
数据库快照将继承快照创建时其源数据库的安全约束。 由于快照是只读的,因此无法更改继承的权限,对源数据库的更改权限将不反映在现有快照中。
如果源数据库的状态为 RECOVERY_PENDING,可能无法访问其数据库快照。 但是,当解决了源数据库的问题之后,快照将再次变成可用快照。
只要理解它的原理它的限制也就自然明了。
创建数据库快照
在创建数据库之前,首先要知道数据库分布在几个文件上,因为快照需要对每一个文件进行copy-on-writing。
先查看数据库有几个数据库文件:
1 2 3 |
|
我的数据库只有一个数据库文件,所以直接执行以下脚本创建快照:
1 2 3 4 5 |
|
如果数据库存在于文件组,可能涉及多个数据库文件创建快照的示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
数据库快照恢复和删除
1 2 3 4 5 6 7 |
|
原文地址:https://www.cnblogs.com/gered/p/9519031.html