SQL Server中事务日志自动增长对性能的影响（下）

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

升级总结： 　　看上去当事务日志不增长的时候，性能会得到改善，特别是写入时。 　　删除命令 　　这个测试的目标同删除一样，也有更新与插入。 　　我向表中插入10，000行然后运行以下代码来删除所有行： 　　– Truncate the table 　　truncate table ExpandDB 　　go 　　– Truncate the T-Log 　　backup transaction ShrinkDB with truncate_only 　……

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

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

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

升级总结：

　　看上去当事务日志不增长的时候，性能会得到改善，特别是写入时。

　　删除命令

　　这个测试的目标同删除一样，也有更新与插入。

　　我向表中插入10，000行然后运行以下代码来删除所有行：

　　-- Truncate the table
　　truncate table ExpandDB
　　go
　　-- Truncate the T-Log
　　backup transaction ShrinkDB with truncate_only
　　go
　　-- Shrink T-Log back to 2MB:
　　DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
　　Go
　　-- Delete 10,000:
　　declare @i int
　　set @i = 1
　　while @i <= 10000
　　begin
　　insert into ExpandDB select replicate （'a',1000）
　　set @i = @i + 1
　　end
　　go
　　-- Truncate the T-Log
　　backup transaction ShrinkDB with truncate_only
　　go
　　-- Shrink T-Log back to 2MB:
　　DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
　　go
　　-- Delete 10,000:
　　delete from ExpandDB
　　-- Check size and % free space in T-Log
　　dbcc sqlperf（logspace）
　　go

　　在第一步中，事务日志被缩减，autogrowth被设定为1MB。在第二步中，事务日志没有缩减丙炔他设定的足够大以至于不会增长。

　　下面是结果对比：

　　删除总结：

　　再次证明，事务日志不增长，性能就会越好，特别是在整个期限里。CPU差异呈现锯齿状情况（可能因为数量太少所以不精准）。

　　事务中的更多行

　　为测试大量事务的相关性能（事务日志自动增长），我重复了上面的测试，将行数改为50，000行（之前是10，000行），测试结果如下所示：

　　插入：

　　更新：

　　删除：

　　看上去，在事务日志不增长的情况下，事务越多性能改进越大。

　　更大的autogrowth

　　为测试更大autogrowth的相关性能，我将事务日志的autogrowth设置为50MB，然后连续三次运行以下代码（包括插入删除）：

　　

 -- Truncate the table
　　truncate table ExpandDB
　　go
　　-- Truncate the T-Log
　　backup transaction ShrinkDB with truncate_only
　　go
　　-- Shrink T-Log back to 2MB:
　　DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
　　Go
　　-- Insert 50,000 rows
　　begin tran
　　declare @i int
　　set @i = 1
　　while @i <= 50000
　　begin insert into ExpandDB select replicate （'a',1000）
　　set @i = @i + 1
　　end
　　commit
　　Go
　　-- Truncate the T-Log
　　backup transaction ShrinkDB with truncate_only
　　Go
　　-- Shrink T-Log back to 2MB: DBCC SHRINKFILE （N'ShrinkDB_Log' , 0, TRUNCATEONLY）
　　Go
　　-- Delete 50,000: delete from ExpandDB
　　-- Check size and % free space in T-Log
　　dbcc sqlperf（logspace）
　　Go
　　然后我对比了前两次的结果（50，000行、不同的autogrowth）：

　　插入：

　　删除：

　　结果显示事务日志增长越少，性能越佳。

　　测试结果总结——第二阶段

　　根据测试结果，我可以证明当事务日志在运行中增长时，它会对性能产生负面影响：

　　1、事务越多，性能受影响越大;

　　2、更新的行数越多，声场的T-Log越大;

　　3、Autogrowth越小，性能的影响越大。

　　注意我的测试只包含一个单独运行的事务。那么在多用户环境中，事务日志增长之后会发生什么？我将在今后的测试中继续研究。

　　另注：

　　同样的问题，测试证明了在一些数据库中，事务日志里的大量虚拟日志文件影响了数据修改的整体性能。这样的话，建议主动增长事务日志，不要让它自动增长。对于另外一些数据库，建议使用大的autogrowth（指大小而不是百分比）。

作者

Michelle Gutzait
Michelle Gutzait

翻译

孙瑞
孙瑞

相关推荐