博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
SQL Server 2008备份策略设计上(五)
阅读量:5985 次
发布时间:2019-06-20

本文共 3022 字,大约阅读时间需要 10 分钟。

无论是数据库Dev还是DBA,都希望关键业务数据库的完整性和可用性能得到保障,数据库备份是一种不错的选择。SQL Server 2008支持不同应用层次的多种备份方式,为我们的业务数据提供了强有力的保障,这一篇博文就来探讨如何在SQL Server 2008下设计合理的备份策略。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

为了设计合理的备份策略,首先要熟悉SQL Server 2008都支持哪些恢复模式,它支持的恢复模式有如下:

 
翻译后如下:
 
 
简单恢复模式:

在简单恢复模式下,只支持完整备份和差异备份,不支持事务日志备份。在简单恢复模式下还原数据库时只能还原到上一次数据库备份的数据,而上一次数据库备份以后的数据将无法进行还原,在发生灾难时,这些上一次数据库备份以后的数据必须重做。所以简单恢复模式并不适用于生产系统。另外在简单恢复模式下,由于事务日志会被截断,所以日志文件不会一直膨胀,非常小。

完整恢复模式:

完整恢复模式是微软建议在生产环境中使用的恢复模式。在正常情况下(即能备份日志尾部)发生灾难进行还原数据库时,不会丢失任务数据。但是如果日志尾部损坏,则必须重做自上一次日志备份或差异备份等之后所做的更改。在完整恢复模式下,所有的操作都会在日志中完整地记录下来。

大容量日志恢复模式:

大容量日志恢复模式简单地记录了大多数大容量操作日志(Bulk INSERT,CREATE INDEX,SELECT INTO),而不是记录全部大容量操作日志,所以这些大容量操作比在完整恢复模式下执行要快很多,同时大容量日志恢复模式完整记录了其他事务日志。所以大容量日志恢复模式是一种特殊用途的恢复模式,只应用于提高某些大规模大容量操作(如大量数据的大容量导入)的性能。完整恢复模式下有关备份的许多说明也适用于大容量日志恢复模式。

如果在最新日志备份后发生日志损坏或执行大容量日志记录操作,则必须重做自该上次备份之后所做的更改,否则不丢失任何数据。

另外设计合理的备份策略,还要熟悉SQL Server 2008都支持哪些备份类型,它支持的备份类型有如下:

 
 
翻译后如下:
 

 

完整数据库备份:

完整备份会备份数据库中的所有数据,以及可以恢复这些数据的足够的日志。它为差异、事务日志备份创建基准备份。在数据库底层上,完整备份实际上是把所有页(page)复制到备份设备上。

差异数据库备份:

差异备份仅备份自上次完整备份后发生更改的数据。通常,建立基准备份之后执行的差异备份比基准备份更小,创建速度也更快。因此,使用差异备份可以加快进行频繁备份的速度,从而降低数据丢失的风险。通常,一个差异基准会由若干个相继的差异备份使用。还原时,首先还原完整备份,然后再还原最后一个的差异备份。
业务数据库运行一段时间后,随着数据库的更新,包含在差异备份中的数据量会增加。这使得创建和还原差异备份的速度变慢。因此,必须重新创建一个完整备份,为另一个系列的差异备份提供新的差异基准。

同样,差异备份和完整备份类似,也会备份恢复数据的足够日志,这是由数据库系统控制的。

在数据库底层上,差异备份是备份自上次完整备份以后所有修改的区(extent)

部分备份:

部分备份与完整数据库备份类似,但是部分备份不包含所有文件组。部分备份包含主文件组、每个读写文件组以及任何指定(可选)的只读文件中的所有数据。部分备份在希望不包括只读文件组时非常有用。只读数据库的部分备份仅包含主文件组。

部分备份功能从SQL Server 2005开始引入。
创建部分备份时,必须在BACKUP 语句中指定 READ_WRITE_FILEGROUPS 选项。也可以指定任何只读文件或文件组,以便将其包括在部分备份中。

事务日志备份:

在完整恢复模式或大容量日志恢复模式下,需要定期进行事务日志备份。每个日志备份都包括创建备份时处于活动状态的部分事务日志,以及先前日志备份中未备份的所有日志记录。在创建第一个事务日志备份之前,必须先创建完整备份(如完整数据库备份或一组文件备份中的第一个完整备份)。此后,必须定期备份事务日志。这不仅能最小化工作丢失风险,还有助于事务日志的截断。通常,事务日志在每次常规日志备份之后截断。

连续的日志备份序列称为日志链。日志链从数据库的完整备份开始。通常,仅当第一次完整备份数据库时或者将恢复模式从简单恢复模式切换到完整恢复模式或大容量日志恢复模式之后,才会开始一个新的日志链。在完整恢复模式下(或者在大容量日志恢复模式下的某些时候),连续不断的日志链可以将数据库还原到任意时间点。

若要将数据库还原到故障点,必须保证日志链是完整的。也就是说,事务日志备份的连续序列必须能够延续到故障点。此日志序列的开始位置取决于所还原的数据备份类型:数据库备份(包括完整或差异备份)、部分备份或文件备份。对于数据库备份或部分备份,日志备份序列必须从数据库备份或部分备份的结尾处开始延续。对于一组文件备份,日志备份序列必须从整组文件备份的开头开始延续。

如果日志备份丢失或损坏,则可通过创建完整数据库备份或差异数据库备份并随后备份事务日志来开始一个新的日志链。如果要将数据库还原到事务日志备份内的某个时点,则建议保留丢失的日志备份之前的事务日志备份。

尾日志备份:

在完整恢复模式或大容量日志恢复模式下数据库发生灾难时,SQL Server 20052008可以备份日志结尾以捕获尚未备份的活动日志记录,把还原数据库操作之前对日志尾部执行的日志备份称为尾日志备份。

所以这里面有一点特别重要,在完整恢复模式或大容量日志恢复模式下一旦数据库发生灾难,还原数据库时,进行的第一步操作是尾日志备份(如果尾日志能备份的话),这样才不会丢失自上一次日志备份(也可能是完整或差异备份,主要是看用什么备份策略)后的数据。如果日志文件受损且无法创建结尾日志备份,则必须在不使用结尾日志备份的情况下还原数据库。最新日志备份(也可能是完整或差异备份,主要是看用什么备份策略)后提交的任何事务都将丢失。

文件和文件组备份:

针对大型数据库和性能要求使完整数据库备份显得不切实际时,则可以创建文件备份。文件备份包含一个或多个文件(或文件组)中的所有数据。文件备份包括完整文件备份和差异文件备份。针对大型数据库可以分别备份和还原数据库中的文件,而且可以仅还原已损坏的文件,而不必还原数据库的其他部分。

差异文件备份为创建当前文件备份提供了一种快速并且节省空间的方式。在简单恢复模式下,仅为只读文件组启用了差异文件备份。在完整恢复模式下,允许对具有差异基准的任何文件组进行差异文件备份。

文件和文件组备份增加了备份和还原的复杂度。

Copy_only备份:

仅复制备份可以在不打断正常备份序列的情况下复制数据库的内容,这个功能从SQL Server 2005开始引入。事务日志从不在仅复制备份后出现截断,这对平时DEVDBA仅想获得一份完整的数据库用于测试工作,而又不影响当前的备份序列非常方便。

 

敲文字敲到手软,哈哈,算是对恢复模式和备份类型的全面总结,因为恢复模式和备份类型对设计一种合理的备份策略太重要了,希望对大家有用。下一篇继续写SQL Server 2008备份策略设计。

 

 

转载地址:http://uculx.baihongyu.com/

你可能感兴趣的文章
一个ECS上自建Oracle数据库的案例的相关实践
查看>>
调整vmware虚拟机硬盘空间大小
查看>>
yum使用之小练习
查看>>
杀死linux的僵尸进程
查看>>
scrapy随机更改User-Agent方法
查看>>
最近蹿红的(伪)自动驾驶土豆,是怎么做出来的?
查看>>
我的 PHP Zend Framework(ZF) 框架教程连载
查看>>
【原理总结】STP生成树机制
查看>>
双击IE7会生成快捷方式的处理
查看>>
i7 cpu 以及计算机系统赏析
查看>>
svnserve.conf:12: Option expected的问题解决方法
查看>>
多种思路解决Keepalived限制死20个VIP问题
查看>>
实现DUA设备更新代理的相关资源
查看>>
第一个shell
查看>>
allot管理口无法通讯
查看>>
NFS服务器配置
查看>>
Nginx + webpy 和FastCGI搭建webpy环境
查看>>
Filter滤镜
查看>>
GRE over IPSEC 同时NAT-T(Profile PAT)
查看>>
Windows Phone 7 框架和页面
查看>>