ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.

事务日志仅仅是记录与其对应数据库上的事务行为和对数据库修改的日志文件(.ldf文件)

在SQL Server对于日志文件的管理，是将逻辑上一个ldf文件划分成多个逻辑上的虚拟日志文件(virtual log files,简称VLFs).以便于管理。用个类比方法来看，日志文件(ldf)好比一趟火车，每一节车厢都是一个虚拟日志文件(VLFs):

因为SQL Server通过这种方式使得存储引擎管理事务日志更加有效.并且对于日志空间的重复利用也会更加高效。使用VLF作为收缩数据库的最小单位比使用ldf文件作为最小单位无疑是更加高效的.

即使事务已经到了Commit阶段，也仅仅只是把缓冲区（内存中）的日志页写入日志(磁盘上)，并没有把数据写入数据库.那将要修改的数据页写入数据库是在何时发生的呢?

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

- 完整备份并不像其名字“完整”那样备份所有部分，而是仅备份数据库本身，而不备份日志(虽然仅仅备份少量日志用于同步）

- 完整备份在备份期间，数据库是可用的。完整备份会记录开始备份时的LSN号，结束备份时的LSN号，以便在备份结束时将这期间的改动应用到备份，所以完整备份后数据的时间点是备份结束的时间。

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

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

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

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

这就涉及到了一个概念—最小恢复LSN（Minimum Recovery LSN（MinLSN） ）

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

- CheckPoint的开始LSN

- 还未结束的事务在日志的最小LSN

- 尚未传递给分发数据库的最早的复制事务起点的 LSN.

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

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

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

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

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

- 活动(Active) –在VLF 上存储的任意一条LSN是活动的时，则VLF则为活动状态，即使一个200M的VLF只包含了一条LSN，如上图的VLF3

- 可恢复(Recoverable) – VLF是不活动的，VLF上不包含活动LSN,但还未被截断(truncated)

- 可重用(Reusable) – VLF是不活动的，VLF上不包含活动LSN,已经被截断(truncated)，可以重用

- 未使用(Unused) – VLF是不活动的,并且还未被使用过

而所谓的截断(truncated)只是将可恢复状态的VLF转换到可重用状态。在简单恢复模式下，每一次CheckPoint会引发一次截断.而每一次CheckPoint都会将MinLSN向后推.所以当事务结束后并且过了CheckPoint点，其相关的日志将会被截断以便重复利用空间。

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

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

在完整恢复模式下，CheckPoint不会截断日志。只有对日志的备份才会将MinLSN向后推并截断日志。因此在一个业务量稍大的系统中，日志的增长速度将会变得很快。

在DB_1处做了完整备份，并且接下来两次分别做了两次日志备份(Log_1和Log_2),在Log_2备份完不久服务器由于数据所在磁盘损坏。这时如果日志文件完好，则可以通过备份尾部日志(Tail of log)后，从DB_1开始恢复，依次恢复Log_1,Log_2,尾部日志来将数据库恢复到灾难发生时的时间点。理论上可以使数据的损失为0。

从日志恢复数据的原理是Redo,也就是将日志中记载的事务再重做一遍。这个开销和从完整或差异备份中恢复相比，要大很多。因此尽可能的减少利用日志的恢复量。而使用完整或者差异备份来恢复更多的数据。

大容量恢复模式在很多地方和完整恢复模式相同。但由于在完整恢复模式下，对数据库的每一项操作都会记录在日志中。而对于某些大量数据的导入导出操作，无疑会在日志中留下大量记录。很多情况下，我们并不需要将这些信息记录在日志中。

连续的日志备份被称之为日志链。表示日志是连续的.这个概念可以用下图表示:

1.复制数据阶段:从完整备份和差异备份中将数据，索引页和日志复制到被恢复数据库文件。

2.Redo(roll forward)阶段:将记录在日志中的事务应用到从备份中复制过来的数据。使数据Roll Forward到指定的时间点.这个阶段完成后，数据库还处于不可使用阶段:

上面两部就是Restore

3.Undo(Roll Back)阶段:这也是传说中的Recovery，将任何未提交的事务回滚。这个阶段过后，数据库处于可用状态。任何后续备份将不能接着应用到当前数据库。

在连续两个日志链的日志备份，在第一个事务日志备份中定义的事务，在第二个事务日志备份中Commit.如果在第一个事务日志还原后使用了Recovery选项.也就是经历了Undo阶段。则事务1在Undo阶段会被回滚：

可见，日志备份1中的T1被回滚，在日志备份2中的Commit也就毫无意义。这也就是为什么经历过Undo阶段后不允许再恢复后续备份。因此，微软推荐的最佳实践是使用NoRecovery选项不进行Undo阶段。而在所有备份恢复后单独进行Undo阶段,这个操作可以通过还原日志尾部时，指定Recovery选项进行。

前面说过，日志文件中的LSN号是可以比较的，如果LSN2>LSN1,则说明LSN2的发生时间晚于LSN1的发生时间。CheckPoint或Lazy Writer通过将日志文件末尾的LSN号和缓冲区中数据文件的LSN进行对比，只有缓冲区内LSN号小于日志文件末尾的LSN号的数据(注意这里写的是数据页，而不在是日志，即上图的椭圆形区域步骤)才会被写入到磁盘中的数据库。因此确保了WAL（在数据写入到数据库之前，先写入日志)。