(2.6)备份与还原--在简单恢复模式下事务日志的角色

简介

在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性。并不承担具体的恢复数据的角色。正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先要了解SQL Server提供的几种不同备份类型。

SQL Server提供的几种备份类型

SQL Server所提供的几种备份类型基本可以分为以下三种(文件和文件组备份以及部分备份不在本文讨论之列):

1.完整(Full)备份:直接将所备份的数据的所有区(Extent)进行复制。这里值得注意的有2点:

  • 完整备份并不像其名字“完整”那样备份所有部分,而是仅备份数据库本身,而不备份日志(虽然仅仅备份少量日志用于同步)
  • 完整备份在备份期间,数据库是可用的。完整备份会记录开始备份时的MinLSN号,结束备份时的LSN号,将这个区间的日志进行备份,在恢复时应用到被恢复的数据库(这里经过修改,感谢魔君六道指出)

2.差异(Differential)备份:只备份上次完整备份后,做修改的部分。备份单位是区(Extent)。意味着某个区内即使只有一页做了变动,则在差异备份里会被体现.差异备份依靠一个BitMap进行维护,一个Bit对应一个区,自上次完整备份后,被修改的区会被置为1,而BitMap中被置为1对应的区会被差异备份所备份。而到下一次完整备份后,BitMap中所有的Bit都会被重置为0。

3.日志(Log)备份:仅仅备份自上次完整备份或日志备份之后的记录。在简单模式下,日志备份毫无意义(SQL Server不允许在简单恢复模式下备份日志),下文会说明在简单恢复模式下,为什么日志备份没有意义。

简单恢复模式(Simple Recovery Mode)

在简单恢复模式下,日志仅仅是为了保证SQL Server事务的ACID。并没有恢复数据的功能.

比如,我们有一个备份计划,如下:

我们在每周一0点做一次完整备份,在周三0点和周五0点分别做差异备份。在简单恢复模式下,如果周六数据库崩溃。我们的恢复计划只有根据周一0点的做的完整备份恢复后,再利用周五0点的差异备份进行恢复.而周五0点之后到服务器崩溃期间所有的数据将会丢失。

正如”简单”这个词所涵盖的意思,在简单恢复模式下,日志可以完全不用管理。而备份和恢复完全依赖于我们自己的完整和差异备份.

恢复模式是一个数据库级别的参数,可以通过在SSMS里或通过SQL语句进行配置:

简单恢复模式下日志的空间使用

在本系列文章的第一篇文章提到过,日志文件会划分成多个VLF进行管理,在逻辑上记录是线性的,给每个记录一个顺序的,唯一的LSN。

而在简单恢复模式下,为了保证事务的持久性,那些有可能回滚的数据会被写入日志。这些日志需要被暂时保存在日志以确保在特定条件下事务可以顺利回滚。这就涉及到了一个概念—最小恢复LSN(Minimum Recovery LSN(MinLSN) )

MinLsn是在还未结束的事务记录在日志中最小的LSN号,MinLSN是下列三者之一的最小值:

  • CheckPoint的开始LSN
  • 还未结束的事务在日志的最小LSN
  • 尚未传递给分发数据库的最早的复制事务起点的 LSN.

下图是一个日志的片段:

(图片摘自MSDN)

可以看到,最新的LSN是148,147是CheckPoint,在这个CheckPoint之前事务1已经完成,而事务2还未完成,所以对应的MinLSN应该是事务2的开始,也就是142.

而从MinLSN到日志的逻辑结尾处,则称为活动日志(Active Log)。

而活动日志分布在物理VLF上的关系可以用下图表示:

因此,VLF的状态是源自其上所含有的LSN的状态,可以分为两大类:活动VLF和不活动VLF

而更加细分可以将VLF的状态分为以下四类:

  1. 活动(Active) –在VLF 上存储的任意一条LSN是活动的时,则VLF则为活动状态,即使一个200M的VLF只包含了一条LSN,如上图的VLF3
  2. 可恢复(Recoverable) – VLF是不活动的,VLF上不包含活动LSN,但还未被截断(truncated)
  3. 可重用(Reusable) – VLF是不活动的,VLF上不包含活动LSN,已经被截断(truncated),可以重用
  4. 未使用(Unused) – VLF是不活动的,并且还未被使用过

概念如下图:

而所谓的截断(truncated)只是将可恢复状态的VLF转换到可重用状态。在简单恢复模式下,每一次CheckPoint,都会去检查是否有日志可以截断.如果有inactive的VLF时,CheckPoint都会将可截断部分进行截断,并将MinLSN向后推.

在日志达到日志文件(ldf文件)末尾时,也就是上图的VLF8时,会重新循环到VLF1开始,以便让空间进行重复利用.所以日志虽然可以从物理顺序上是从VLF1到VLF8,但逻辑顺序可以是从VLF6开始到VLF2结束:

因此可以看出,简单恢复模式下日志是不保存的(当事务结束后,相关的会被截断)。仅仅是用于保证事务回滚和崩溃恢复的用途.所以备份日志也就无从谈起,更不能利用日志来恢复数据库。

总结

本文介绍了简单恢复模式下日志的原理,并简单的引出了一些备份或者恢复数据的基础。而实际上,除了在开发或测试环境下。使用简单恢复模式的场景并不多,因为在现实生活中,在生产环境允许几个小时的数据丢失的场景几乎没有.下篇文章将会讲述在完整恢复模式下,日志的作用。

转自:http://www.cnblogs.com/CareySon/archive/2012/02/17/2355200.html

原文地址:https://www.cnblogs.com/gered/p/9178609.html

时间: 2024-10-17 05:22:51

(2.6)备份与还原--在简单恢复模式下事务日志的角色的相关文章

(2.8)备份与还原--在大容量恢复模式下事务日志的角色

简介 日志的作用是保证持久性和数据一致性,通过日志可以实现数据的Undo与Redo,因此通过日志,SQL Server不仅仅可以实现灾难恢复,还可以通过日志的Redo来实现高可用性.本篇文章主要讲述日志在SQL Server中提供的几种高可用性中的作用以及在灾难恢复中的角色. 日志损坏 日志可能会由于IO子系统的故障而损坏,当出现日志损坏时,如果您对日志的原来略有了解,并能在日志损坏的情况下尽量挽救数据,那么感觉一定是非常好的:-),下面我们来了解几种日志损坏的情况下的恢复情况. 1.数据库正常

(2.7)备份与还原--在完全恢复模式下事务日志的角色

简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会小.而墨菲定律(事情如果有变坏的可能,无论这种可能性有多小,它总会发生)仿佛是给DBA量身定做的.在上篇文章介绍的简单恢复模式下,从最近一次备份到当前的数据都会存在丢失的风险.而完整备份模式使得数据丢失的风险大大减少.本文主要介绍在完整备份模式下概念原理和日志所处的角色. 完整(Full)恢复模式 完整恢复模式通过将对数据库的任何修改记录到日志来给予数据最大程度的保护.在完整恢复模式下,日志的作用不仅仅是保证了数

解决简单恢复模式下产生的日志增长

简介 最近测试服务器进行数据归档,其间程序员发现一个问题,空间不足,我查看原因发现日志文件暴涨.然后将数据库改为简单恢复模式,但是依然存在这个问题.经过查询资料发现了日志文件在简单模式下依然增加的原因. Simple概念 Simple恢复模式也叫做”Checkpoint with truncate log“,其实这个名字更形象,在Simple模式下,SQL Server会在每次checkpoint或backup之后自动截断log,也就是丢弃所有的闲置日志记录,仅保留用于实例启动时自动发生的ins

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色

浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 本篇文章是系列文章中的第三篇,前两篇的地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 简介 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.在开始文章之前,首先

sql server 备份与恢复系列三 简单恢复模式下的备份与还原

原文:sql server 备份与恢复系列三 简单恢复模式下的备份与还原 一.概述 前面讲了备份的一些理论知识,这篇开始讲在简单恢复模式下的备份与还原.在简单模式下是不能做日志备份的,发生灾难后,数据库最后一次备份之后做的数据修改将是全部丢失的,所以在生产环境下,数据又很重要,一般不建议使用这种模式. 例如对一个数据库有5次完整数据备份,时间是t5,  之后发生灾难,就会部丢失. 当数据库越来越大,完整备份时间会越来越长,为了减少丢失风险,引入差异备份.例如下图演示:在第一次建立数据库完整备份后

SQL Server中的事务日志管理(4/9):简单恢复模式里的日志管理

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这个标题近乎是用词不当,因为很大程度上,运行在简单模式里不需要日志管理.在简单模式里,事务日志的唯一目的是在数据库恢复操作期间,保证事务的ACID属性,还有强制数据库的一致性和事务的持久性.事务日志不能被备份,不能用来数据库恢复,也不能用作日志传输. 在简单模式

数据库完整恢复模式下的日志增长问题

最近在弄alwaysOn的时候有遇到磁盘满了的情况,这个是因为参与alwaysOn的数据库必须是完整恢复模式, 而完整恢复模式,数据库收缩还无效果,所以只能采用事务日志备份的方式来进行事务日志截断. 这个还要感谢@i6first大神和@桦仔大神的文章才了解到必须使用事务日志备份才可行(原谅我是小白一枚,竟然不知道完整恢复模式需要用事务日志备份才能解决日志大小问题.目前还在成长中..).开此文章,用于记录完整模式下日志增长问题. 论证如下 ↓↓↓↓ ------------------------

事务日志初探(二)---简单恢复模式

简述 在简单恢复模式下,日志文件的作用仅仅是保证了SQL Server事务的ACID属性.并不承担具体的恢复数据的角色.正如”简单”这个词的字面意思一样,数据的备份和恢复仅仅是依赖于手动备份和恢复.我们简单介绍下三种恢复模式. 1.完整恢复模式 这种模式会为所有操作都记录日志,当数据文件被破坏时,可以备份尾部事务日志,并用于将数据库还原到给定的时间点.因此OLTP生产系统通常会使用完整的恢复模式. 2.大容量日志恢复模式 这种模式把日志记录量最小化,只为大容量操作记录日志. 3.简单恢复模式 我

浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色

浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色 本篇文章是系列文章中的第四篇,也是最后一篇,本篇文章需要前三篇的文章知识作为基础,前三篇的文章地址如下: 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色 浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色 简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会