SQLServer数据库的备份计划方案

2017/3/8 17:21:50 人评论 次浏览 分类:SQL



关键词: 数据库维护,维护计划,方案,常用方案,数据库备份,数据库备份方案,SQLServer,MSSQL,完整备份,差异备份,事务日志备份


数据的维护计划有很多种,维护任务 、检查数据库完整性 、收缩数据库 、重新组织索引 、重新生成索引 、更新统计信息 、清除历史记录 、执行SQL Server代理作业 、备份数据库(完整、差异、事务日志) ,今天来说一下数据库维护计划中的备份数据的方案。

在项目之后一般都需要为数据库创建数据库的备份计划确保项目在运行的过程数据库出现问题的时候可以进行回滚。在数据库备份计划中一般比较常见也比较容易的进行全量备份,很多新手一般选择1-2次的全量备份,以为这样就完成了数据库的备份计划,到后面出了问题之后才后悔莫及。一些访问量比较大的网站分分秒秒都产生很多数据,仅靠1-2次的全量备份是不够的。所以我们需要了解数据库维护计划的种类和使用范围来建立适合项目要求的数据库维护计划方案。

注重数据的备份工作是数据库管理员必须时刻关注的一项任务,也是必须周期性重复操作的一项工作。

下面说一下完整备份、差异备份、日志备份的原理和使用场景

完整备份(full backup)
完整备份会生成一个数据库的拷贝。当数据库备份操作执行时,数据库对于数据库活动(当数据库处于在线活动状态)来说仍然处于可用状态。在所有的数据库备份选项当中,完整数据库备份是最耗时间的。完整备份包含备份操作完成时刻的所有数据改变和日志文件。一旦生成一个完整数据库备份,它允许你恢复整个数据库。完整备份是数据恢复计划的核心,而且它是利用事务日志或差异备份的先决条件。当创建备份时,可以选择在磁盘上创建文件或直接写到磁带上。通常情况下,当SQL Server 备份直接写入磁盘时,备份执行并完成得更快。一旦创建了备份,可以把它复制到磁带上。

差异备份(differential backup)
复制最后一次完整备份之后的所有数据和日志页。由于当数据库备份时它是处于在线状态的,因此差异备份包含从备份开始到备份结束时间点发生的数据改变和日志文件。通过差异备份产生的文件通常要比完整数据库备份的小,并且创建得更快。
差异备份不像事务日志备份,它是自包含的并且只需要要还原的数据库最后的完整备份。但是事务日志备份是序列文件并且不包含前一个事务日志备份的数据。例如,如果你在上午9点运行完整备份,在上午11点进行差异备份,并且在下午2点进行一个补充的差异备份,下午2点的差异备份将仍然包含上午8点的完整备份之后发生的数据改变:

  时  间  
 备份类型
上午9点
完整数据库备份
上午11点
差异备份(捕捉上午8点—上午10点的数据改变)
下午2点
差异备份(捕捉上午8点—下午1点的数据改变)
 
事务日志备份(transaction log backup)
备份了最后的完整备份或事务日志备份完成后发生的事务日志的活动。当备份完成后,SQL Server截断日志不活动的部分(这部分不包含打开的事务活动)。事务日志备份具有低资源消耗的特性,并且可以频繁执行(例如,每15分钟执行一次)。
事务日志逐条记录了已经提交的事务,及那些已经打开但仍没有提交的事务。这些文件包含正在进行事务的记录以及数据库内的改变。
从事务日志备份中恢复,必须先从完整备份中还原,然后再附加事务日志备份。事务日志是积累的,意思是每一个备份都是事务日志备份序列的一部分,而且必须以相同的顺序连续地还原。比如说,你不能在还原完整数据库备份之后就还原第三个事务日志备份,而跳过前两个事务日志备份。

总结:差异备份和事务日志备份都是基于完整备份的,所以完整备份是必须的,也是作为基线而存在的。最后一次差异备份都是基于上一次完整备份的,所以差异备份会越来越大,但是还原的时候只需要使用最后一次差异备份,事务日志也是基于最后一次完整备份,但是事务日志备份的大小是随机,在还原的时候是从上次完整备份的还原开始逐个还原,如果中间出现缺失,整个事务日志备份还原就会失败。

案例:
1.下面列出一个典型的备份序列:
时  间  
备份类型
上午8点
完整数据库备份
上午10点
事务日志备份
下午1点
事务日志备份
下午3点
差异备份
a.如果希望将数据库恢复到下午1点,如何做?
步骤:首先需要还原上午8点的完整备份,下一步还原上午10点的事务日志备份,最后是下午1点的事务日志备份。

b.如果希望将数据库恢复到下午3点,如何做?
如果是使用差异备份,必须先还原完整备份,下一步是还原差异备份。


常用方案
根据上述的对比我们知道由于完整备份的体积比较大,备份的时间比较长,所以要降低完整备份的频率。差异是增量备份,会累积上次完整备份之后的所有变化。所以完整备份的时间也不宜太长。事务日志的备份体积最小,而且备份的时间很快,所以适合高频率的执行。

推荐以下的备份方案:(各位也可以选择适合不同项目的备份计划方案)
a.每周一次完整备份  
b.每天一次差异备份  
c.每1个小时一次事务日志备份(如果是一周的一次完整备份,产生的事务日志还是很多的)
d.删除备份,由于备份文件越来越多,磁盘空间是有限的,一般需要定期清理一下备份文件

相信经过上述的说明大家理解了数据库备份计划的种类和原理,应该也心里有底,不怕数据库发生异常之后无法回滚到最新的状态。


相关资讯

  • SqlServer通过TRUNCATE快速删除数据库表

    对于需要快速删除数据库的某个表的数据的时候,如果我们使用Delete 的操作删除数百万级以上的数据,一般速度都不理想,而且在执行Delete操作的过程如果发生中断的话就会进行自动的rollback回滚数据。因为在执行delete的操作的时候,数据库时候会将删除的操作记录在数据库日志中…

    2017/1/26 15:31:56
  • MySQL服务无法启动出现错误1067,进程意外终止的解决方法

    在给系统打补丁之后就需要重启。第二天发现MySQL服务无法自启动,然后尝试手动重启也不行。提示“windows无法启动mysql服务,位于本地计算机上。错误1067:进程意外终止”。然后用“错误1067:进程意外终止”去百度,按照搜索结果前面操作方法试试,发现还是无法启动mysql服务…

    2016/6/24 18:47:08
  • mysql的innodb_force_recovery参数说明

    innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0,表示当需要恢复时执行所有的恢复操作。当不能进行有效的恢复操作时,mysql有可能无法启动,并记录下错误日志。

    2016/5/28 15:26:38