再谈SQLServer中日志的的作用

简介 之前我已经写了一个关于SQL Server日志的简单系列文章。本篇文章会进一步挖掘日志背后的一些概念，原理以及作用。如果您没有看过我之前的文章，请参阅： 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)--

简介

&＃160;&＃160;&＃160; 之前我已经写了一个关于SQL Server日志的简单系列文章。本篇文章会进一步挖掘日志背后的一些概念，原理以及作用。如果您没有看过我之前的文章，请参阅：

&＃160;&＃160;&＃160; 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架

&＃160;&＃160;&＃160; 浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色

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

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

&＃160;&＃160;&＃160; 浅谈SQL Server中的事务日志(五)----日志在高可用和灾难恢复中的作用

&＃160;

数据库的可靠性

&＃160;&＃160;&＃160; 在关系数据库系统中，我们需要数据库可靠，所谓的可靠就是当遇见如下两种情况之一时保证数据库的一致性:

&＃160;

SQLServer中的日志

&＃160;&＃160;&＃160; SQL Server中靠日志来维护一致性（当然，日志的作用非常多，但一致性是日志的基本功能，其他功能可以看作是额外的功能）。通常我们创建数据库的时候，会附带一个扩展名为ldf的日志文件。日志文件其实本质上就是日志记录的集合。在SQL Server中，我们可以通过DBCC LOGINFO来看这个日志的信息，如图1所示。

&＃160;&＃160;&＃160;

&＃160;&＃160;&＃160; 图1.DBCC LOGINFO

&＃160;

&＃160;&＃160;&＃160; 该命令可以从VLF的角度从一个比较高的层级看日志。其中值得注意的列是VLF大小，状态（2表示使用，0表示从未使用过），偏移量。对于这些信息对我们规划VLF数量的时候很有帮助，因为VLF过多可能引起严重的性能问题，尤其是在复制等Scale-Out或HA环境下。

&＃160;&＃160;&＃160; 然后，事务对数据库中每次修改都会分解成多个多个原子层级的条目被记录到持久存储中，这些条目就是所谓的日志记录（Log Record），我们可以通过fn_dblog来查看这些条目。如图2所示。

图2.Fn_dblog

&＃160;

&＃160;&＃160;&＃160; 每个日志记录都会被背赋予一个唯一的顺序编号，这个编号大小为10字节，由三部分组成，分别为：

&＃160;

&＃160;&＃160;&＃160; 因此，由于VLF是不断递增的（同一个VLF被复用会导致编号改变），因此LSN序号也是不断递增的。因此，通过上面的LSN结构不难发现，如果比VLF更小的粒度并不是直接对应LOG RECORD，而是LOG Block。Log Block是日志写入持久化存储的最小单位，Log Block的大小从512字节到60K不等，这取决于事务的大小，那些在内存还未被写入持久化存储的Log Block也就是所谓的In-Flight日志。以下两个因素决定Log Block的大小：

&＃160;&＃160;&＃160; 当然，这些仅仅是日志的一小部分内容。通过Log Record所记录的内容，就能够精确的记录对数据库所做的修改。

&＃160;

日志用于Undo

&＃160;&＃160;&＃160; 在了解为了Undo，日志所起的作用之前，我们首先可以了解一下为什么需要事务存在回滚：

&＃160;&＃160;&＃160; 图7中，我们进行一个简单测试，在启动过程中，首先禁用了CheckPoint以防止自动CheckPoint，然后我们修改数据，不提交，并持久化到磁盘。另一个线程修改数据并提交，但未持久化到磁盘。为了简单起见，我把两个线程写到一个窗口中。

&＃160;&＃160;&＃160;

&＃160;&＃160;&＃160; 图7.需要Undo和Redo的两个事务

&＃160;

&＃160;&＃160;&＃160; 此时我们强制杀死SQL Server进程，导致数据本身不一致，此时在SQL Server的重启过程中，会自动的Redo和Undo上面的日志，如图８所示。

&＃160;&＃160;&＃160; 图8.实现Redo和Undo

&＃160;

那么，什么是CheckPoint?

&＃160;&＃160;&＃160; 图８给出的简单例子足以说明Recovery机制。但例子过于简单，假如一个非常繁忙的数据库可能存在大量日志，一个日志如果全部需要在Recovery过程中被扫描的话，那么Recovery过程所导致的宕机时间将会成为噩梦。因此，我们引入一个叫CheckPoint的机制，就像其名称那样，CheckPoint就是一个存档点，意味着我们可以从该点继续开始。

&＃160;&＃160;&＃160; 在Undo/Redo机制的数据库系统中，CheckPoint的机制如下：

１.将CheckPoint标记写入日志（标记中包含当前数据库中活动的事务信息），并将Log Block写入持久化存储

2.将Buffer Pool中所有的脏页写入磁盘，所有的脏页包含了未提交事务所修改的数据

3.将结束CKPT标记写入日志，并将Log Block写入持久化存储

&＃160;

&＃160;&＃160;&＃160; 我们在日志中可以看到的CheckPoint标记如图9所示。

&＃160;&＃160;&＃160;

图9.CheckPoint标记

&＃160;

&＃160;&＃160; 其中，这些Log Record会包含CheckPoint的开始时间，结束时间以及MinLSN，用于复制的LSN等。由图９中我们还可以看到一个LOP_XACT_CKPT操作的Log Record，，该操作符的上下文如果为NULL的话，则意味着当前：

&＃160;&＃160; 由CheckPoint的机制可以看出，由于内存中的数据往往比持久化存储中的数据更新，而CheckPoint保证了这部分数据能够被持久化到磁盘，因此CheckPoint之前的数据一定不会再需要被Redo。而对于未提交的事物所修改的数据写入持久化存储，则可以通过Undo来回滚事务（未提交的事物会导致CheckPoint无法截断日志，因此这部分日志可以在Recovery的时候被读取到，即使这部分日志在CheckPoint之前）。

此时，我们就可以100%的保证，CheckPoint之前的日志就可以被安全删除（简单恢复模式）或归档了（完整恢复模式），在Recovery时，仅仅需要从CheckPoint开始扫描日志，从而减少宕机时间。

&＃160;

小结