数据库快照的工作方式

数据库快照提供源数据库在创建快照时的只读,静态视图,不包含未提交的事务.由于数据库引擎在创建快照后运行恢复,因此未提交的事务在新近创建的数据库快照中回滚(数据库中的事务不受影响).

数据库快照与源数据库相关.数据库快照必须与数据库在同一服务器实例上.此外,如果数据库因某种原因而不可用,则它的所有数据库快照也将不可用.

快照可用于报表.另外,如果源数据库出现用户错误,还可将源数据库恢复到创建快照时的状态.丢失的数据仅限于创建快照后数据库更新的数据.此外,在对数据库进行重大更改(例如,更改表的架构或结构)之前创建数据库快照也很有用.

虽然不一定必须使用快照,但是了解其工作原理会有所帮助.数据库快照在数据页级运行.在第一次修改源数据库页之前,先将原始页从源数据库复制到快照.此过程称为写入时复制操作“.快照将存储原始页,保留它们在创建快照时的数据记录.对已修改页中的记录进行后续更新不会影响快照的内容.对要进行第一次修改的每一页重复此过程.这样,快照将保留自创建快照后经修改的所有数据记录的原始页.

为了存储复制的原始页,快照使用一个或多个稀疏文件“.最初,稀疏文件实质上是空文件,不包含用户数据并且未被分配存储用户数据的磁盘空间.随着源数据库中更新的页越来越多,文件的大小也不断增长.创建快照时,稀疏文件占用的磁盘空间很少.然而,由于数据库随着时间的推移不断更新,稀疏文件会增长为一个很大的文件.

下图说明了写入时复制操作.快照关系图中的浅灰色方框表示稀疏文件中尚未分配的潜在空间.收到源数据库中页的第一次更新时,数据库引擎将写入文件,操作系统向快照的稀疏文件分配空间并将原始页复制到该处.然后,数据库引擎更新源数据库中的页.下图说明了此类写入时复制操作.

重要提示:由于数据库快照不是冗余存储,因此,它们不会防止磁盘出现错误或其他类型的损坏.为了保护数据库,非常有必要定期执行备份并测试还原计划.如果必须将源数据库还原到创建数据库快照的时间点,请实施允许您执行该操作的备份策略.

 

对数据库快照的读操作

对于用户而言,数据库快照似乎始终保持不变,因为对数据库快照的读操作始终访问原始数据页,而与页驻留的位置无关.如果未更新源数据库中的页,则对快照的读操作将从源数据库读取原始页.下图显示了对新创建的快照(因此其稀疏文件不包含页)的读操作.此读操作仅从源数据库读取.

更新页之后,对快照的读操作仍访问原始页,该原始页现在存储在稀疏文件中.下图说明了对访问源数据库中更新页的快照的读操作.此读操作从快照的稀疏文件中读取原始页.

 

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

如果您的源数据库过大并且您担心磁盘空间使用量,则您应该在某个时候用新快照替换旧快照.快照理想的使用期限取决于其增长率以及可用于其稀疏文件的磁盘空间.快照所需的磁盘空间取决于在快照使用期限内源数据库中更新的不同页的数量.因此,如果大多数情况下更新重复更新的页的小子集,则随着时间的推移,增长率会降低,快照所需空间也会相对较小.相反,如果最终将所有原始页至少更新一次,则快照将会增长到源数据库的大小.如果磁盘将满,则快照会互相争用磁盘空间.如果磁盘驱动器已满,则无法将操作写入所有快照.

因此,在计划快照预计使用期限内所需空间量时,了解数据库的通常更新模式是很有用的.对于某些数据库,更新率可能相当稳定;例如,库存数据库可能每天都更新很多页,这对每天或每周替换旧快照非常有用.对于其他数据库,更新页的比例在业务周期内可能有所不同;例如,目录数据库可能通常每季度更新,会在其他时间偶尔更新;逻辑策略是在每季度更新前后创建快照.如果发生严重更新错误,允许还原更新前快照,而更新后快照用于报告下一季度的写入.

下图说明了两种相对的更新模式对快照大小的影响.更新模式 A 反映的是在快照使用期限内仅有 30% 的原始页更新的环境.更新模式 B 反映的是在快照使用期限内有 80% 的原始页更新的环境.

 

数据库快照的元数据

对于数据库快照,数据库元数据包括 source_database_id 属性,该属性存储在 sys.databases 目录视图的列中通常,数据库快照不公开自己的元数据,但会公开源数据库的元数据.例如,此元数据包括下列语句返回的数据:

USE <database_snapshot> SELECT * FROM sys.database_files

其中,<database_snapshot>是数据库快照的名称.

唯一的例外情况是当源数据库使用全文搜索或数据库镜像时,此时由于更改了快照元数据中的一些值,因此在快照上禁用了源数据库.

尾日志备份

对于大多数情况,在完整恢复模式或大容量日志恢复模式下,SQL Server 2005 及更高版本要求您备份日志结尾以捕获尚未备份的日志记录.还原操作之前对日志尾部执行的日志备份称为结尾日志备份“.

SQL Server 2005 及更高版本通常要求您在开始还原数据库前执行结尾日志备份.结尾日志备份可以防止工作丢失并确保日志链的完整性.将数据库恢复到故障点时,结尾日志备份是恢复计划中的最后一个相关备份.如果无法备份日志尾部,则只能将数据库恢复为故障前创建的最后一个备份.

并非所有还原方案都要求执行结尾日志备份.如果先前的日志备份中包含恢复点,或者您准备移动或替换(覆盖)数据库,则不一定需要结尾日志备份.并且,如果日志文件受损且无法创建结尾日志备份,则必须在不使用结尾日志备份的情况下还原数据库.最新日志备份后提交的任何事务都将丢失

备份日志尾部

结尾日志备份与任何其他日志备份类似,使用 BACKUP LOG 语句执行.建议下列情况下执行结尾日志备份:

  • 如果数据库处于联机状态,每当您准备对数据库执行的下一个操作为还原操作时,请在开始还原顺序之前使用WITH NORECOVERY 备份日志尾部:
    BACKUP LOG 
    数据库名称 TO <备份设备> WITH NORECOVERY

注意:为防止出错,必须使用 NORECOVERY 选项(指定不发生回滚).

  • 如果数据库处于脱机状态并且无法启动.
    尝试执行结尾日志备份.由于此时不会发生任何事务,所以 WITH NORECOVERY 是可选的.如果数据库受损,请使用 WITH CONTINUE_AFTER_ERROR 
     WITH NO_TRUNCATE.
    BACKUP LOG 
    数据库名称 TO <备份设备> [WITH { CONTINUE_AFTER_ERROR | NO_TRUNCATE }

重要提示:除非数据库受损,否则不建议使用 NO_TRUNCATE.

如果数据库受损(例如,数据库无法启动),则仅当日志文件未受损,数据库处于支持结尾日志备份的状态并且不包含任何大容量日志更改时,结尾日志备份才能成功.

BACKUP LOG 选项

注释

NORECOVERY

每当您准备对数据库继续执行还原操作时,请使用 NORECOVERY.NORECOVERY使数据库进入还原状态.这确保了数据库在结尾日志备份后不会更改.

除非同时指定 NO_TRUNCATE  COPY_ONLY 选项,否则将截断日志.

{ CONTINUE_AFTER_ERROR | NO_TRUNCATE }

仅当您要备份受损数据库的尾部时才能使用 NO_TRUNCATE CONTINUE_AFTER_ERROR.

注意:对受损数据库备份日志尾部时,日志备份中正常捕获的部分元数据可能不可用.

在数据库损坏时创建事务日志备份

  • 如何在数据库损坏时备份事务日志 (Transact-SQL)
  • 如何备份事务日志 (SQL Server Management Studio)

包含不完整备份元数据的结尾日志备份

结尾日志备份可捕获日志尾部,即使数据库脱机,损坏或缺少数据文件.这可能导致还原信息命令和 msdb 生成不完整的元数据.但只有元数据是不完整的,而捕获的日志是完整且可用的.

如果结尾日志备份包含不完整的元数据, backupset 表中的 has_incomplete_metadata 将设置为 1.此外,RESTORE HEADERONLY 的输出中,HasIncompleteMetadata 将设置为 1.

如果结尾日志备份中的元数据不完整, backupfilegroup 表在结尾日志备份时将丢失文件组的大多数相关信息.大多数 backupfilegroup 表列为 NULL;只有以下几列有意义:

  • backup_set_id
  • filegroup_id
  • type
  • type_desc
  • is_readonly

不使用结尾日志备份执行还原

不需要结尾日志备份的还原方案包括以下几种:

  • 将数据库还原到先前日志备份中包含的某个时间点.
    如果还原一个数据库并在还原顺序中的每个 RESTORE 语句中指定 STOPAT,STOPATMARK STOPBEFOREMARK 选项,则不必进行结尾日志备份.

将数据库还原到先前时间点

  • 若要使用 Transact-SQL 还原到特定时间点,请参阅如何还原到某个时间点 (Transact-SQL),恢复到标记的事务或恢复到日志序列号 (LSN).
  • 若要使用 SQL Server Management Studio,请参阅如何还原到某个时点 (SQL Server Management Studio)或如何将数据库还原到标记的事务 (SQL Server Management Studio).
  • 将数据库副本还原到新位置.
    当您还原数据库时,只有将数据库还原到不同的服务器实例时,才可以使用相同的数据库名称,例如,创建镜像数据库用于数据库镜像或创建辅助数据库用于日志传送.如果在同一服务器实例上移动数据库,您必须为数据库指定新名称.

将数据库还原到新位置

  • 在还原顺序的每个 RESTORE 语句中,使用 Transact-SQL 指定 MOVE 选项.
  • 使用 SQL Server Management Studio,

对于大多数情况,在完整恢复模式或大容量日志恢复模式下,SQL Server 2005 及更高版本要求您备份日志结尾以捕获尚未备份的日志记录.还原操作之前对日志尾部执行的日志备份称为”结尾日志备份”.

SQL Server 2005 及更高版本通常要求您在开始还原数据库前执行结尾日志备份.结尾日志备份可以防止工作丢失并确保日志链的完整性.将数据库恢复到故障点时,结尾日志备份是恢复计划中的最后一个相关备份.如果无法备份日志尾部,则只能将数据库恢复为故障前创建的最后一个备份.

并非所有还原方案都要求执行结尾日志备份.如果先前的日志备份中包含恢复点,或者您准备移动或替换(覆盖)数据库,则不一定需要结尾日志备份.并且,如果日志文件受损且无法创建结尾日志备份,则必须在不使用结尾日志备份的情况下还原数据库.最新日志备份后提交的任何事务都将丢失

备份日志尾部

结尾日志备份与任何其他日志备份类似,使用 BACKUP LOG 语句执行.建议下列情况下执行结尾日志备份:

  • 如果数据库处于联机状态,每当您准备对数据库执行的下一个操作为还原操作时,请在开始还原顺序之前使用 WITH NORECOVERY 备份日志尾部:
    BACKUP LOG 
    数据库名称 TO <备份设备> WITH NORECOVERY

注意:为防止出错,必须使用 NORECOVERY 选项(指定不发生回滚).

  • 如果数据库处于脱机状态并且无法启动.
    尝试执行结尾日志备份.由于此时不会发生任何事务,所以 WITH NORECOVERY 是可选的.如果数据库受损,请使用 WITH CONTINUE_AFTER_ERROR 
     WITH NO_TRUNCATE.
    BACKUP LOG 
    数据库名称 TO <备份设备> [WITH { CONTINUE_AFTER_ERROR | NO_TRUNCATE }

重要提示:除非数据库受损,否则不建议使用 NO_TRUNCATE.

如果数据库受损(例如,数据库无法启动),则仅当日志文件未受损,数据库处于支持结尾日志备份的状态并且不包含任何大容量日志更改时,结尾日志备份才能成功.

BACKUP LOG 选项

注释

NORECOVERY

每当您准备对数据库继续执行还原操作时,请使用NORECOVERY.NORECOVERY 使数据库进入还原状态.这确保了数据库在结尾日志备份后不会更改.

除非同时指定 NO_TRUNCATE  COPY_ONLY 选项,否则将截断日志.

{ CONTINUE_AFTER_ERROR | NO_TRUNCATE }

仅当您要备份受损数据库的尾部时才能使用 NO_TRUNCATE CONTINUE_AFTER_ERROR.

注意:对受损数据库备份日志尾部时,日志备份中正常捕获的部分元数据可能不可用.

在数据库损坏时创建事务日志备份

  • 如何在数据库损坏时备份事务日志 (Transact-SQL)
  • 如何备份事务日志 (SQL Server Management Studio)

 

包含不完整备份元数据的结尾日志备份

结尾日志备份可捕获日志尾部,即使数据库脱机,损坏或缺少数据文件.这可能导致还原信息命令和 msdb 生成不完整的元数据.但只有元数据是不完整的,而捕获的日志是完整且可用的.

如果结尾日志备份包含不完整的元数据, backupset 表中的 has_incomplete_metadata 将设置为 1.此外,RESTORE HEADERONLY 的输出中,HasIncompleteMetadata 将设置为 1.

如果结尾日志备份中的元数据不完整, backupfilegroup 表在结尾日志备份时将丢失文件组的大多数相关信息.大多数 backupfilegroup 表列为 NULL;只有以下几列有意义:

  • backup_set_id
  • filegroup_id
  • type
  • type_desc
  • is_readonly

不使用结尾日志备份执行还原

不需要结尾日志备份的还原方案包括以下几种:

  • 将数据库还原到先前日志备份中包含的某个时间点.
    如果还原一个数据库并在还原顺序中的每个 RESTORE 语句中指定 STOPAT,STOPATMARK STOPBEFOREMARK 选项,则不必进行结尾日志备份.

将数据库还原到先前时间点

  • 若要使用 Transact-SQL 还原到特定时间点,请参阅如何还原到某个时间点 (Transact-SQL),恢复到标记的事务或恢复到日志序列号 (LSN).
  • 若要使用 SQL Server Management Studio,请参阅如何还原到某个时点 (SQL Server Management Studio)或如何将数据库还原到标记的事务 (SQL Server Management Studio).
  • 将数据库副本还原到新位置.
    当您还原数据库时,只有将数据库还原到不同的服务器实例时,才可以使用相同的数据库名称,例如,创建镜像数据库用于数据库镜像或创建辅助数据库用于日志传送.如果在同一服务器实例上移动数据库,您必须为数据库指定新名称.

将数据库还原到新位置

  • 在还原顺序的每个 RESTORE 语句中,使用 Transact-SQL 指定 MOVE 选项.
  • 使用 SQL Server Management Studio,还原数据库(选项)还原为字段中指定每个文件的新位置.
  • 完整替换(覆盖)数据库.

注意:应当尽量避免使用 REPLACE 选项执行还原,并且只有经验丰富的数据库管理员在慎重考虑后才能这样做.

  • PLACE 选项.
  • 使用 SQL Server Management Studio,还原数据库(选项)还原为字段中指定每个文件的新位置.
  • 还原数据库(选项)还原为字段中指定每个文件的新位置.
  • 完整替换(覆盖)数据库.

注意:应当尽量避免使用 REPLACE 选项执行还原,并且只有经验丰富的数据库管理员在慎重考虑后才能这样做.

  • PLACE 选项.
  • 使用 SQL Server Management Studio,还原数据库(选项)还原为字段中指定每个文件的新位置.

数据库快照的限制和要求

数据库快照捕获开始创建快照的时间点,去掉所有未提交的事务.使用数据库快照之前,应了解数据库快照对源数据库和系统环境的影响,以及快照本身存在哪些限制.

重要提示:只有 MicrosoftSQL Server 2005 Enterprise Edition 和更高版本才提供数据库快照功能.

源数据库存在的限制

只要存在数据库快照,快照的源数据库就存在以下限制:

  • 不能对数据库进行删除,分离或还原.

注意:可以备份源数据库,这方面将不受数据库快照的影响.

  • 源数据库的性能受到影响.由于每次更新页时都会对快照执行写入时复制操作,导致源数据库上的 I/O 增加.
  • 不能从源数据库或任何快照中删除文件.
  • 源数据库必须处于联机状态,除非该数据库在数据库镜像会话中是镜像数据库.

注意:所有恢复模式都支持数据库快照.

  • 不能将源数据库配置为可缩放共享数据库.
  • 若要在镜像数据库中创建数据库快照,数据库必须处于同步镜像状态.

数据库快照的限制

数据库快照存在以下限制:

  • 数据库快照必须与源数据库在相同的服务器实例上创建和保留.
  • 始终对整个数据库拍摄数据库快照.
  • 数据库快照与源数据库相关.因此,使用数据库快照还原数据库不能代替备份和还原策略.严格按计划执行备份仍然至关重要.如果必须将源数据库还原到创建数据库快照的时间点,请实施允许您执行该操作的备份策略.
  • 当将源数据库中更新的页强制压入快照时,如果快照用尽磁盘空间或者遇到其他错误,则该快照将成为可疑快照并且必须将其删除.
  • 快照为只读.
  • 禁止对 model 数据库,master 数据库和 tempdb 数据库创建快照.
  • 不能更改数据库快照文件的任何规范.
  • 不能从数据库快照中删除文件.
  • 不能备份或还原数据库快照.
  • 不能附加或分离数据库快照.
  • 不能在 FAT32 文件系统或 RAW 分区上创建数据库快照.数据库快照所用的稀疏文件由 NTFS 文件系统提供.
  • 数据库快照不支持全文索引.不从源数据库传播全文目录.
  • 数据库快照将继承快照创建时其源数据库的安全约束.由于快照是只读的,因此无法更改继承的权限,对源数据库的更改权限将不反映在现有快照中.
  • 快照始终反映创建该快照时的文件组状态:联机文件组将保持联机状态,脱机文件组将保持脱机状态.有关详细信息,请参阅本主题后面的”含有脱机文件组的数据库快照”.
  • 如果源数据库的状态为 RECOVERY_PENDING,可能无法访问其数据库快照.但是,当解决了源数据库的问题之后,快照将再次变成可用快照.
  • 只读文件组和压缩文件组不支持恢复操作.
  • 在日志传送配置中,只能针对主数据库,而不能针对辅助数据库创建数据库快照.如果您在主服务器实例和辅助服务器实例之间切换角色,则在将主数据库设置为辅助数据库之前,必须先删除所有数据库快照.
  • 不能将数据库快照配置为可缩放共享数据库.
  • 数据库快照不支持 FILESTREAM 文件组.如果源数据库中存在 FILESTREAM 文件组,则它们在数据库快照中被标识为脱机状态,且其数据库快照不能用于恢复数据库.

注意:对数据库快照执行的 SELECT 语句不能指定 FILESTREAM ;否则,将返回如下错误消息:由于数据移动,无法继续以 NOLOCK 方式扫描.

磁盘空间要求

数据库快照占用磁盘空间.如果数据库快照用尽了磁盘空间,将被标记为可疑,必须将其删除.(但是,源数据库不会受到影响,对其执行的操作仍能继续正常进行.)然而,与一份完整的数据库相比,快照具有高度空间有效性.快照仅需足够存储空间来存储在其生存期中更改的页.通常情况下,快照只会保留一段有限的时间,因此其大小不是主要问题.

但是,保留快照的时间越长,越有可能将可用空间用完.稀疏文件最大只能增长到创建快照时相应的源数据库文件的大小.

如果数据库快照用完了磁盘空间,则必须删除该快照.

注意 除文件空间外,数据库快照与数据库占用的资源量大致相同.

含有脱机文件组的数据库快照

当您尝试执行下列任何操作时,源数据库中的脱机文件组都将影响数据库快照:

  • 创建快照
    当源数据库具有一个或多个脱机文件组时
    ,快照创建只有在文件组处于脱机状态时才能成功.不能为脱机文件组创建稀疏文件.
  • 使文件组脱机
    可以在源数据库中使文件脱机
    .但是,如果创建快照时文件组处于联机状态,则该文件组在数据库快照中仍将保持联机状态.如果查询的数据在快照创建后已更改,则在快照中可以访问原始数据页.但是,使用快照访问文件组中未修改数据的查询可能会由于出现输入/输出 (I/O) 错误而失败.
  • 使文件组联机
    只要数据库具有任何快照
    ,就不能使其中的文件组联机.如果在创建快照时文件组处于脱机状态,或当数据库快照存在时使文件组脱机,则文件组将保持脱机状态.这是因为使文件重新联机需要还原该文件,而如果数据库已具有快照,则无法执行此操作.
  • 将源数据库恢复到快照
    将源数据库恢复到数据库快照要求除创建快照时处于脱机状态的文件组外
    ,所有文件组都要处于联机状态.

数据库快照简介

数据库快照功能是在 MicrosoftSQL Server 2005 中新增的功能.只有 SQL Server 2005 Enterprise Edition 和更高版本才提供数据库快照功能.所有恢复模式都支持数据库快照.

数据库快照是数据库(源数据库)的只读,静态视图.多个快照可以位于一个源数据库中,并且可以作为数据库始终驻留在同一服务器实例上.创建快照时,每个数据库快照在事务上与源数据库一致.在被数据库所有者显式删除之前,快照始终存在.

与用户数据库的默认行为不同,数据库快照是通过将 ALLOW_SNAPSHOT_ISOLATION 数据库选项设置为 ON 而创建的,不需要考虑主数据库或模型系统数据库中该选项的设置.

快照可用于报表.另外,如果源数据库出现用户错误,还可将源数据库恢复到创建快照时的状态.丢失的数据仅限于创建快照后数据库更新的数据.

重要提示 :无法对脱机或损坏的数据库进行恢复.因此,为了保护数据库,非常有必要定期执行备份并测试还原计划.

注意:数据库快照与快照备份,事务的快照隔离或快照复制无关.