在该系列第一部分有关数据库文件压缩的文章中，我们测试并证实了事务中数据文件增长时的性能实质（performance implications）。在该事务日志情况下，还存在着潜在的性能问题。

事务日志通常比数据库文件增长得要快，并且在数据库管理员也会更加经常对它们进行压缩。在本篇技巧中，我将测试事务中事务日志文件的影响。在本文的示例中，我用到的是和前一篇技巧相同的环境和配置，唯一不同的地方就是我在SQL Server上安装的SP3。

数据库

我测试的数据库为ShrinkDB，我将它设置为在事务过程中不允许数据库文件增长。但是事务日志文件大小仅仅为2 MB，测试目标为让每个事务增长。

ShrinkDB数据库恢复模式：设置为FULL。

以上查询中，fileid为事务日志文件，返回值为 256。这就是说事务日志文件页数为8 KB，大小为2 MB。

在我上一篇文章中，再一次用到了ExpandDB表。

测试

测试目标为了解INSERT、UPDATE和DELETE命令和事务日志之间是如何相互影响的。

我将整个测试分为两个阶段：

• 在第一阶段，我监测到了事务日志增长相关操作程序修改的一般行为。
• 在第二阶段，我只用到了在第一阶段中促使事务日志增长的那些命令。在这一阶段，我测试了和第一部分中相同的自动增长情况。

由于更新、插入和删除表现各不相同，每个阶段都包含三个部分，一下每项操作就是一个部分：UPDATES， INSERTS和DELETE。

第一阶段：事务日志增长行为

UPDATE命令和事务日志增长

在本次测试中，代码仅仅在表中插入一行，并且在事务日志文件增长到8 MB（1，024页）时，代码将自动更新这个行。

结果让人觉得很吃惊。事务日志文件并没有增长并且事务日志中闲置空间所占百分比一直为30%以上（这个百分比是由 dbcc sqlperf(logspace)计算出来的）。在事务中，事务日志会一直填充至70%，然后减少至50%左右。为了保证我能从dbcc sqlperf中获得正确数据，我还可以运行报告（report）查询数据库文件的自动增长率。