尽管我们很想避免这种情况，但对事务日志的内部结构以及处理它的内部流程进行一些讨论，对于理解适当的日志维护技术非常有帮助。这一主题在文献、文章中都有详细介绍了解SQL Server中的日志记录和恢复保罗·兰达尔和这本书SQL Server 2008内部由卡伦·德莱尼（Kalen Delaney）撰写，这是两个很好的例子，所以我们将在这里保持简短。

虚拟日志文件

事务日志文件是相继的文件夹；换句话说，SQL Server按顺序写入事务日志（与数据文件不同，数据文件往往以随机方式写入，因为数据是在随机数据页中修改的）。

插入日志文件的每个日志记录都带有逻辑序列号(LSN（伦敦证券交易所代码）). 当第一次创建数据库及其关联的日志文件时，第一条日志记录将标记逻辑文件的开始，在这个阶段，逻辑文件将与物理文件的开始重合。LSN不断增加；最新添加的日志记录将始终具有最高的LSN，并标记逻辑文件的结尾（稍后将详细讨论）。与给定事务关联的所有日志记录都链接在LSN链具有指向当前操作之前成功的事务中的操作的前向和后向指针。

在内部，SQLServer将事务日志文件划分为多个部分，这些部分称为虚拟日志文件（甚低频）。图1描述了由八个VLF组成的事务日志，并标记了日志的活动部分。

图2.1:8个VLF的事务日志

正如级别1中所讨论的，任何与打开事务相关的日志记录都是可能回滚所必需的。此外，数据库中还有各种其他活动（包括复制、镜像和更改数据捕获），它们使用事务日志，并需要保留事务日志记录，直到处理完为止。带有最小LSN如图2.1所示，定义为“成功的数据库范围回滚所需的最旧日志记录或由其他人 数据库中的活动或操作“。这有时被称为日志的“头”。

最新的日志记录将始终具有最高的LSN，如图2.1所示最大LSN，这标志着日志的逻辑结束。所有后续记录都会写入日志的逻辑末尾。文件中位于最小LSN记录和日志的逻辑结尾称为活动日志.

需要注意的是，活动日志并不只是包含“活动”（即打开的）事务的详细信息。例如，考虑这样一种情况，MinLSN由一个开放事务（T1）的日志记录定义，该事务在上午9点开始，运行需要30分钟。如果后续事务（T2）在上午9点10分开始，9点11分结束，它仍将是活动日志的一部分，因为相关日志记录的LSN将大于MinLSN。在上午9点30分，当T1提交时，新的MinLSN可能由上午9点25分开始的开放事务（T3）的日志记录定义。此时，T2的日志记录将不再是活动日志的一部分。

任何包含活动日志任何部分的VLF都被视为活动VLF。例如，图2.1中的VLF3是一个活动VLF，尽管它包含的大多数日志记录都不是活动日志的一部分。随着事务的开始和提交，我们可以想象（有点简单地）日志的头部在图2.1中从左向右移动，因此以前包含部分活动日志的VLF现在变为非活动日志（VLF 1和2），而以前未被触及的VLF（VLF8）将成为活动日志的一部分。

如何将VLF标记为“非活动”取决于数据库使用的恢复模型，我们将在下面讨论。

日志截断和空间重用

这里需要注意的一点非常重要，日志文件中截断的最小单位不是单个日志记录或日志块，而是VLF。如果VLF中只有一条日志记录仍然是活动日志的一部分，那么整个VLF都被认为是活动的，并且无法截断.

广义而言，VLF可以处于两种物理状态之一：积极的或非活动的然而，基于VLF可能的不同“行为”，我们可以识别四种逻辑状态：

1. 活动–VLF是指此状态处于活动状态，因为它包含至少一个属于活动日志的日志记录，因此回滚或其他目的需要此记录
2. 可恢复–VLF是指此状态处于非活动状态，但未被截断或备份。空间无法重复使用
3. 可重复使用的–VLF是指此状态为非活动状态。它已被截断或备份，空间可以重复使用
4. 未使用的–VLF是指该状态处于非活动状态；它没有记录任何日志记录

将VLF标记为非活动的行为（就逻辑状态而言，这意味着从状态2切换到状态3）称为日志截断。

何时发生这种截断取决于使用的恢复模型。当数据库位于简单恢复模型中，通过检查点过程的发生，可以使活动VLF处于非活动状态。当检查点发生时，缓存中的任何脏页都会被刷新到磁盘，然后日志中的空间就可以重用了。

然而，在FULL（满）或散装 已记录模型中，只有日志备份才能将活动VLF更改为非活动VLF。在这种情况下，一旦日志备份备份了日志，它就会将不再需要的任何VLF标记为非活动的，因此可以重用。

在图2.2中，我们可以看到，由于检查点（或日志备份），VLF1和VLF2被截断并且处于非活动状态。逻辑日志的开始现在是VLF3的开始。VLF8仍未使用，因此仍处于非活动状态（状态4）。

图2.2:8个VLF的事务日志，截断后。

下一个要考虑的问题是当活动日志到达VLF7末尾时会发生什么。最容易想到的是，日志文件中的空间是以循环的方式被重用的，尽管有一些复杂的因素有时会使空间重用模式显得相当武断，我们不打算在这个Stairway中深入研究。

然而，在最简单的情况下，一旦日志的逻辑末尾到达VLF的末尾，SQL Server将开始重用下一个不活动的连续VLF。在图1中，这将是VLF8。VLF8满后，它将环绕并重用VLF1和2。如果根本没有其他VLF可用，日志将需要自动拖动并添加更多VLF。如果由于自动增长被禁用或存储日志文件的磁盘已满，因此无法执行此操作，则活动日志的逻辑端将与日志文件的物理端相遇，事务日志已满，并将发出9002错误。

这个体系结构解释了为什么，例如，一个非常长时间运行的事务，或者由于某种原因尚未发送到分发数据库的复制事务，或者一个断开连接的镜像，会导致日志变得非常大。例如，考虑图2.2中的情况，与MinLSN关联的事务运行时间很长。日志已被环绕，填充了VLF 1、2和8，并且不再有非活动VLF。即使在提交MinLSN之后启动的每个事务，也不能重用这些VLF中的任何空间，因为所有VLF仍然是活动日志的一部分。

我们可以很容易地看到这一点。首先，重新运行清单1.1以删除并重新创建测试数据库数据库。然后创建一个小示例表，在显式事务中更新表中的一行，并使事务保持打开状态（不要承诺它）。在SSMS的第二个选项卡中，运行清单1.2到1.4中的脚本。这一次你应该看到空间不日志备份后可供重用。但是，如果您随后提交事务并重新运行日志备份，则会发生这种情况。

为了方便起见，Level 1中的相关代码文件包含在该Stairway的代码中——请参阅本文末尾的链接。

在这种情况下，如果活动日志占用的“区域”非常大，并且有大量不可重用的空间，那么在某些情况下，日志文件的大小将不得不增加（并不断增长……）。其他可能延迟日志文件截断的因素将在中进行讨论级别8–帮助，我的日志已满.

VLF过多？

通常，SQL Server决定要分配的VLF的最佳大小和数量。然而，一个以小增量频繁自动浏览的事务日志将有大量的小VLF。这种现象被称为日志碎片在某种程度上，我们可以通过重复Level 1中的简单示例，同时使用名为DBCC LogInfo的命令询问VLF架构，来看到它的实际作用。为了方便起见，本示例所需的脚本包含在可下载文件中（请参阅本级别末尾）。

只需重新运行清单1.1即可删除并重新创建测试数据库数据库。然后，运行基本DBCC公司日志信息表命令，如清单2.1所示。

--有多少VLF？DBCC登录信息GO（开始）

清单2.1：新创建的VLF中有多少个测试数据库数据库？

我们现在不关心返回的任何列的含义；只需注意，返回了四行，这意味着我们有四个VLF。现在，运行清单1.3将一百万行插入日志测试表，在测试数据库数据库，然后重新运行DBCC公司日志信息表命令，如清单2.2所示。

--现在有多少VLF？DBCC登录信息GO（开始）

清单2.2:中有多少VLF测试数据库在插入一百万行后创建数据库？

请注意，我们现在返回了135行，这意味着我们有135个VLF！从模型数据库规定日志文件的初始大小较小，然后以相对较小的增量增长。这些属性不适用于受此类活动影响的数据库，并导致创建大量VLF。

日志文件碎片会对性能产生相当大的影响，尤其是崩溃恢复、恢复、日志备份；换句话说，就是读取日志文件的操作。我们将在中对此进行更详细的讨论级别7–确定Tra的大小和增长nsaction日志，并演示如何通过正确调整日志文件的大小来避免碎片。然而，为了让您了解它可能产生的影响，林奇·谢在将一个具有20000个VLF的数据库与一个具有16个VLF数据库进行比较时，已经证明了对数据修改性能的巨大影响。

最终，日志文件中VLF的“合理”数量问题将取决于日志的大小。一般来说，微软认为大约200多个VLF可能会引起关注，但在一个非常大的日志文件（比如500 GB）中，只有200个VLF也可能是一个问题，因为VLF太大，限制了空间重用。金伯利·特里普的文章“事务日志VLF-太多还是太少？“更详细地讨论了这个问题。

总结

在此级别中，我们介绍了有关事务日志体系结构的最低背景信息，这些信息是理解日志文件中与截断、空间重用和碎片化相关的基本问题和潜在问题所必需的。

在下一个级别中，我们将详细讨论如何在数据库还原和恢复中使用事务日志。