【TechTarget中国原创】我经常能看到人们忙着建立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数据库配置
有以下查询语句：
select size from sysfiles where fileid = 1
Returns: 256 |
文件大小：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。
我为数据库文件还规定了一个目标文件大小， 所以在第一个执行的循环中，插入的行数应达到数据文件和目标文件大小相同的标准：
while （select size from sysfiles where fileid = 1） <=
insert into ExpandDB select replicate （'a',8000）） |
这个循环向ExpandDB中插入了8000字节的行，直到数据库文件大小超出X。ExpandDB表是一个一般关系表，没有索引和约束条件，这样可以避免特殊优化和索引的开销。
在运行完第一个循环并达到目标文件大小时，为作比较我还要执行相同的插入但不增加文件。所以，我必须截短表并清理事务日志来确保T-Log也不增长。
输入以下查询：
select count（*） from ExpandDB
返回第一循环中插入行的数量，
select size from sysfiles where fileid = 1
返回新数据库中的数据文件大小。
以下语句将截短表和T-Log：
truncate table ExpandDB
go
backup transaction ShrinkDB with truncate_only
go |
下面一步是执行同样的插入命令：
declare @i int
set @i = 1
while @i <=
begin
insert into ExpandDB select replicate （'a',8000）
set @i = @i + 1
end |
第一循环结束后，就是表中的行数。
另一件重要的事就是在执行第一第二循环之前一定要清除缓存，只有这样才能确保一个公平的性能比较并清除缓存造成的不平等：
DBCC DROPCLEANBUFFERS
最后，每个测试都要执行三次（三个循环）以保证结果的相容性。
所以，每次测试的第一步是确保数据文件达到初始大小。例如，缩减数据库文件：DBCC SHRINKFILE （N'ShrinkDB' , 0, TRUNCATEONLY）