【数据库事务日志碎片原理分析与方案】-分析篇

前言:说都数据库的事务日志，可以说我们是再熟悉不过的了。一般而言，我们都没有必 要去关心事务日志中的虚拟日志文件的个数。这里提到的“虚拟日志文件”的概念，我们 后面会进行专门的讲述。很多的时候，我们在建立数据库的时候，都采用了它的默认配置， 即:将日志的增长方式设定为“自动增长”，这样会直接导致一个后果就是“文件碎片”， 从而直接导致整个数据库的性能严重下降。那么，如何避免这种情况?如何识别碎片问题? 如何解决问题?这就是我们本篇文章要讲述的内容了。

首先，我们来看看什么是“虚拟日志文件”。

我们知道，在正常的数据库操作中，SQL Server 会以顺序的方式去写日志文件，记录 DLL
和 DML 的操作的详细信息。每一个日志记录都有一个与之相关的逻辑序列号(LSN)。这 些 LSN 处于不断增长的状态，这就是说 LSN2 的日志记录所代表的操作在 LSN1 之后进行。 并且最近添加的日志记录的 LSN 号码最大。

在 SQL Server 内部，SQL Server 将日志文件的空间划分为很多不同的“块”，也称之为 “虚拟日志文件”(VLF)。看看到下面的一个图:

SQL Server 首先将会把事务的详细信息记录到第一个可用的 VLF 中，此时也就是写到 VLF1 中。并且，在写的过程中，日志记录是按照顺序写入的，也就是说首先会写满 VLF1，然 后写 VLF2，以此类推。如果最后全部的 VLF 都写满了之后，日志会循环写入，也就说， 日志会再在写入 VLF1 中，将 VLF1 中之前的日志记录覆盖，当然，这个写入是有条件的， 即:只有在 VLF1 是可重用的情况下才能写入。

到这里，大家可能会有很多的问题，其中一个就是:如何知道 VLF1 现在是否可被重用。 先不急，接着看。

为了使得大家对日志的写入有一个更好的理解，我们通过下面的一个图来说明:

上面的图描述了一个简单的场景:一个事务 T1，T3 已经提交，而 T2，T4 处于运行状态， 并且在 LSN10 的地方执行一个 CheckPoint 操作。

现在我们的有 4 个 VLF 文件，每一个 VLF 中都包含了 4 个事物日志记录。这些日志记录包 含了四个事务的详细信息。在图中，LSN1 表明这个事务 T1 开始的点，LSN2 记录 T1 事务 执行的一个 Update 操作的详细信息，LSN3 记录了 T1 事务执行了 Commit 操作，LSN4， 又是另外一个事务 T2 开始的点，以此类推。

注意:完全可以存在一个事务的日志记录跨越多个 VLF，道理很简单，大家自己想想。

从上面的图中可以看出，现在存在 2 个活动的事务(T2，T4)。而 LSN4 是最先活动事务 T2 的开始点。

在图中还有一个所谓的 MinLSN，就是最先开始的一条活动的日志记录。执行 CheckPoint 的地方是 MaxLSN，就是活动日志最后的点，因为后面还没有写入新的日志记录。其实所 谓的活动日志，主要是因为这些日志有可能被用来执行回滚操作。

在这里朋友们可能就要问了:在上图中,T3 中的事务不是已经提交了吗，应该不属于活动 日志啊?

确实，原本应该是这样的，但是在 T3 之后，又开始了 T4，而且还没有提交，从而使得 T3 处于没有提交的事务 T2 和 T4 之间，导致这一连串的都成为“活动的“。我们再把问题 延伸一下:如果在 LSN10 后面又开始了新的事务，而且 T2 事务还没有提交，那么会导致 活动日志的范围变得更大。所以希望这里大家可以明白我的意思。

包含有活动日志的 VLF 就是处于活动的状态，图中的 VLF1-3 都是活动的，如果 VLF 是活 动的，那么就不能被重用。什么意思呢?

我们现在试想一下:如果 T2 事务一直提交，而新的事务不断的在开启，那么最后的结果 就是 VLF1-4 中都包含活动日志，使得所以的 VLF 都是活动的，如果 VLF4 已经空间写完， 此时数据库发现它不能循环的写入，即不能再从 VLF1 开始写，因为 VLF1 是活动的，这个 时候，数据库就分配新的空间，分配新的 VLF，然后再写入。试想，如果总是这样，那么， 势必会导致文件碎片。所以这也是为什么避免事务运行时间过长的原因之一。

为了加深大家的理解，我们看到下面的一个图:

在上图中，此时活动日志包含在 VLF4 中，而 VLF1-3 都是非活动的 ，所以如果日志不断写 入导致 VFL4 写满，此时日志会再次写入 VLF1，然后是 VLF2，以此类推!