收缩事务日志？

Question

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

Answer 1

你为什么要这么做？在正常情况下，它将不会再次增长，无论如何，直到下一个备份。此外，它还分解了不利于性能的文件。最好的做法是不要使用自动增长，这自动意味着不切碎的东西，因此它需要增长。

Answer 2

这完全取决于你说的问题是什么意思。

一般来说，您不需要定期缩小事务日志。

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

片段化

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

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

您想看到的是所有的VLFs都有相同的大小。如果您有一个百分比，或非常小的增长设置，您将得到一个分段事务日志。

而且，不要太少，也不要太多。参见本文：http://www.sqlskills.com/blogs/kimberly/post/Transaction-Log-VLFs-too-many-or-too-few.aspx

那么，您有数百或数千的VLFs吗？它们都大小不同吗？如果是这样，则事务日志是分段的。

修复它

缩小数据文件的片段。收缩事务日志会将其碎片化。

再次运行此代码：

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

状态为2的行是活动的VLF。它可能在中间的某个地方，我们希望它在开始时。您将无法缩小日志超出活动VLF的位置。

多次运行日志备份作业。然后再次运行上述代码。继续这样做，直到活动的VLF位于或接近事务日志的开始。

收缩It

运行此代码以缩小日志文件。

-收缩文件，减少VLFs的数量，从而删除事务日志dbcc收缩文件(‘AdventureWorks2008R2_ log’，1) go

然后返回并运行上述代码来检查您的VLFs。您应该会看到VLFs数量的减少。

您可能不得不重复日志备份/收缩文件例程几次。

浆纱It

在您的系统运行了几个业务周期之后，您应该对它的自然大小有一个很好的了解。因此，在收缩/整理它之后，您将对其进行大小调整。

首先设定增长：

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

然后给它打个号：

-- 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

所以我使用4000 or或8000 or等等。

Autogrow和MaxSize

当您确实希望手动调整文件大小时，请将自动增长打开，这样您就不会被流氓进程捕获。

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

Answer 3

如果在完全恢复模型中对数据库使用事务日志备份，则将检查事务日志，而不需要对其进行收缩。你会发现你的男人需要这样做的特殊情况，但从来没有定期这样做。