收缩事务日志？

为什么不build议收缩事务日志？

你为什么要？在正常情况下，无论如何，它会再次成长，直到enext备份。再加上它会损坏性能不佳的文件。最好的做法是不要使用自动增长function，这意味着不要使自动增长function自动增长。

这一切都取决于你的意思是什么问题。

一般来说，你不需要定期收缩你的事务日志。

但是，有时需要对其进行碎片整理，或在事务失控后恢复空间。

碎片

此代码将显示您的事务日志的内部结构。

-- get list of VLFs use AdventureWorks2008R2 go dbcc loginfo go

你想看到的是你所有的VLF具有相同的大小。如果你有一个百分比，或非常小的增长设置，你最终会有一个零碎的事务日志。

另外，不要太less或太多。看到这篇文章： http : //www.sqlskills.com/blogs/kimberly/post/Transaction-Log-VLFs-too-many-or-too-few.aspx

那么，你有几百甚至几千的VLF吗？他们都是不同的大小？如果是这样，你的事务日志是分散的。

解决它

收缩数据文件将其分割。收缩事务日志会对其进行碎片整理。

再次运行此代码：

 -- get list of VLFs use AdventureWorks2008R2 go dbcc loginfo go

状态为2的行是活动的VLF。这可能是在中间的某个地方，我们希望在一开始。您将无法将日志收缩到活动的VLF位置之外。

运行您的LOG备份工作几次。然后再次运行上面的代码。继续这样做直到活动的VLF位于或接近事务日志的开始位置。

缩小它

运行此代码来缩小您的日志文件。

– 缩小文件，减lessVLF的数量，从而对事务日志进行碎片整理dbcc shrinkfile（'AdventureWorks2008R2_Log'，1）go

然后返回并运行上面的代码来检查您的VLF。你应该看到VLF数量的减less。

您可能需要重复执行几次日志备份/ shrinkfile例程。

调整它

系统运行几个周期后，你应该有一个好的想法，它的天然大小往往是。所以这就是缩小/碎片整理之后的大小。

首先设定增长：

 -- manually set the growth use master go alter database AdventureWorks2008R2 modify file (name = 'AdventureWorks2008R2_Log', filegrowth = 512000kb) go

然后resize：

 -- manually set the log size use master go alter database AdventureWorks2008R2 modify file (name = 'AdventureWorks2008R2_log', size = 4096000kb) go

你的号码当然会有所不同。有一件事是，如果你的日志会很大，比如说32G，不要一次性设置它。相反，把它发展到8G，然后是16G，24G，32G。

还有一件事，避免4G的倍数，以避免4G的错误。请参考此处： http : //www.sqlskills.com/BLOGS/PAUL/post/Bug-log-file-growth-broken-for-multiples-of-4GB.aspx

所以我使用4000MB或8000MB等

自动增长和MaxSize

虽然您确实想要手动调整文件大小，但请保持Autogrow开启状态，以免被stream氓程序拦截。

通常，我不build议设置MaxSize，除非您有多个事务日志共享相同的LUN，或者您有一个定期运行疯狂查询的数据库来填充驱动器。

如果您正在使用FULL恢复模型中的数据库事务日志备份，则将保持事务日志处于检查状态，而不需要缩小事务日志。你会发现你需要这样做的特殊情况，但从来没有定期。

日志收缩不像数据文件收缩那样恶毒。只有在数据库处于简单恢复模式时，才会执行该操作，并且在某个操作之后文件已经增长太多，直到您知道该值不会再增长。你可以把它缩小到一个给定的值，所以它不会在下次交易时再次分配空间，这会导致性能下降。不要定期做。