在SQL Server上测试事务日志的自动增长（一）

日期： 2009-06-30 作者：Michelle Gutzait翻译：孙瑞 来源：TechTarget中国 英文

比起数据库文件，事务日志的增长速度毫不逊色，因此数据库管理员会经常缩减删除事务日志。在本文中，我将对事务日志文件增长造成的影响做一个测试。而在本次测试中，我将使用和上一次测试相同的环境和配置。唯一的不同是，这一次我在SQL Server上安装了SP3。

　　数据库 　　本次测试数据库ShrinkDB设置为在执行事务时，数据库文件不增长，事务日志文件大小只有2MB，而本次测试的目的就是让它在每次事务中都增长以衡量其影响： 　　ShrinkDB数据库的还原模型被设置为FULL。 　　select size from sysfiles where fileid = 2 　　在以上的查询语句中，fil……

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。

比起数据库文件，事务日志的增长速度毫不逊色，因此数据库管理员会经常缩减删除事务日志。在本文中，我将对事务日志文件增长造成的影响做一个测试。而在本次测试中，我将使用和上一次测试相同的环境和配置。唯一的不同是，这一次我在SQL Server上安装了SP3。

　　数据库

　　本次测试数据库ShrinkDB设置为在执行事务时，数据库文件不增长，事务日志文件大小只有2MB，而本次测试的目的就是让它在每次事务中都增长以衡量其影响：

　　ShrinkDB数据库的还原模型被设置为FULL。

　　select size from sysfiles where fileid = 2

　　在以上的查询语句中，fileid代表事务日志文件，返回值256。这表明，事务日志文件大小为2MB。

　　同上一篇文章一样，ExpandDB表再次使用。

　　create table ExpandDB (a varchar(8000))

　　本次测试的目标是了解INSERT, UPDATE和DELETE命令是如何影响事务日志文件的增长的，还有事务日志文件增长反过来如何影响INSERT, UPDATE和DELETE日志的。

　　我把测试分成两个阶段：

　　在第一阶段，我将监测由于运行修改造成事务文件增长的一般行为。

　　在第二阶段，我将用那些在第一阶段造成事务日志增长的命令。在这个阶段，我将测试同第一部分类似的autogrowth情况。

　　由于更新，插入和删除都有所不同，在每个阶段都要包含三个部分，每次一个操作：UPDATES, INSERTS和DELETE。

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

　　UPDATE命令和事务日志增长

　　在这个测试中，我的代码将只向表中插入一行，知道事务日志文件增长到8MB后，它将更新此表。

　　

-- Insert one row into the table
　　insert into ExpandDB select replicate ( 'a',8000)
　　--================================================================
　　-- Update the table until T-Log reaches 8MB
　　while (select size from sysfiles where fileid = 2) <= 1024
　　update ExpandDB set a = replicate ( 'a',8000)
　　go
　　结果令人惊讶！

　　我的循环无限地运行，事务日志文件没有增长而且在使用dbcc sqlperf（日志空间）的空闲空间百分比一直保持30%的增长。事务运行期间，事务日志将持续填充直至70%，然后下降到50%。为确保从dbcc sqlperf得到准确的数据，我同时在数据文件中运行查找autogrowth的报告：

　　此时报告在任何数据库中都没有autogrowth！

　　然后我决定检查有少量更新的大量事务，一次一行，所以我加了一个开始事务：

　　-- Big transaction
　　begin tran
　　while (select size from sysfiles where fileid = 2) <= 1024
　　update ExpandDB set a = replicate ('a',8000)
　　go
　　commit tran

　　这一次，结果同样令人困惑。循环无限地运行，事务日志文件没有超过初始的2MB而且空闲空间百分比一直保持60%的增长。我停止了循环并提交了事务。提交之后，事务日志文件的使用空间甚至少了一点。

　　在另一个UPDATE命令测试中，我向表中插入了10，000并运行了以下代码：

　　

-- Truncate the T-Log
　　backup transaction ShrinkDB with truncate_only
　　go
　　-- Check the size of the T-Log file (RESULT = 2MB)
　　select size from sysfiles where fileid = 2
　　go
　　-- Check % free space in T-Log
　　dbcc sqlperf(logspace)
　　go
　　-- Update 10000 rows at a time
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　update ExpandDB set a = a + 'a'
　　go
　　-- Check % free space in T-Log
　　dbcc sqlperf(logspace)
　　go
　　结果类似。事务日志文件增长了1MB，直到达到10MB大小，之后就不再增长了。无论我执行几次更新动作，空间填满之后又再次下降：

　　我为此寻求解答，但在SQL Server 2005说明书中没找到答案。我还在其它机器上的SQL Server 2005中运行了同样的测试，但结果都一样。

作者

Michelle Gutzait
Michelle Gutzait

翻译

孙瑞
孙瑞

相关推荐