我经常能看到人们忙着建立SQL Server技术维护计划，定期制定关于缩减数据库文件（数据或者T-Log）的工作。在客户调查数据库增长原因之前，我总是建议他们不要缩减数据库文件，特别是不要定期缩减。

　　我和好多人讨论过这个问题，他们更关心硬盘空间而不是主机性能，因此我决定做一个测试来向他们证明，由事务处理导致的数据库文件增长对SQL Server性能的影响有多大。

　　我将测试一下几个增长情况：

　　1、数据库文件增长；

　　2、数据库T-Log增长；

　　3、Tempdb增长；

　　以下是SQL Server数据库文件增长一系列测试的第一部分：

　　测试环境

　　软硬件配置

　　本次测试的软硬件配置如下图所示：

图一：测试系统的软硬件配置

　　SQL Server 2005 SP2, Enterprise Evaluation Edition。

　　电脑有一个本地iSCSI逻辑单元号。

　　数据库配置

　　我创建了一个数据库，命名为ShrinkDB，数据库配置如下图：

图2：ShrinkDB数据库配置

　　有以下查询语句：

　　文件大小：256*8k=2MB。

　　在数据库中，我创建了下面的表：

　　create table ExpandDB （a varchar（8000））

　　预期目标

　　我的目标是做出基于事务大小和数据文件Autogrowth比的性能测试：

　　1、测试1——小autogrowth，少量事务，插入X行；

　　2.、测试2——小autogrowth，少量事务，插入X*Y行（比测试1插入的行数多）；

　　3、测试3——大autogrowth，少量事务，插入X*Y行（同测试2插入的行数一样多）；

　　4、测试4——小autogrowth，在一个事务中插入X*Y行；

　　5、测试5——大autogrowth（同测试3），在一个事务中插入X*Y行；

　　6、测试6——超大autogrowth，少量事务；

　　7、测试7——超大autogrowth，大量事务；

　　我会分析不同的结果并最终得出结论。

　　注意：测试不包含并发性。

　　方法与代码说明

　　针对每个测试，我为数据库文件规定了文件大小个autogrowth比。例如：初始大小=2MB，autogrowth=1MB。

　　我为数据库文件还规定了一个目标文件大小， 所以在第一个执行的循环中，插入的行数应达到数据文件和目标文件大小相同的标准：

　　这个循环向ExpandDB中插入了8000字节的行，直到数据库文件大小超出X。ExpandDB表是一个一般关系表，没有索引和约束条件，这样可以避免特殊优化和索引的开销。

　　在运行完第一个循环并达到目标文件大小时，为作比较我还要执行相同的插入但不增加文件。所以，我必须截短表并清理事务日志来确保T-Log也不增长。

　　输入以下查询：

　　select count（*） from ExpandDB

　　返回第一循环中插入行的数量，

　　select size from sysfiles where fileid = 1

　　返回新数据库中的数据文件大小。

　　以下语句将截短表和T-Log：

　　下面一步是执行同样的插入命令：

　　第一循环结束后，就是表中的行数。

　　另一件重要的事就是在执行第一第二循环之前一定要清除缓存，只有这样才能确保一个公平的性能比较并清除缓存造成的不平等：

　　DBCC DROPCLEANBUFFERS

　　最后，每个测试都要执行三次（三个循环）以保证结果的相容性。

　　所以，每次测试的第一步是确保数据文件达到初始大小。例如，缩减数据库文件：DBCC SHRINKFILE （N'ShrinkDB' , 0, TRUNCATEONLY）