SQL Server日志文件自动收缩

Question

我的数据库是简单恢复模式，我不期待日志文件的指数级增长，但是日志文件的大小变大。

自动收缩是一个很好的解决方案？

将自动收缩影响简单恢复模式的应用程序的性能？是50GB门槛良好的门槛？

谢谢！

Answer 1

从您的评论：

日志文件的大小再次增长至近200GB

我可以假设你的数据库是不是一个很好的候选人autoshrink（从我的实践来说这是一个罕见的情况下，当autoshrink是DB很好的解决方案）。

Recommendations

1. 制作日志文件（S）足够大的初始大小。这是一个试错的过程只是看上去存在空闲空间，而不是太大。决不收缩日志文件来零的自由空间。
2. 让日志不是基于％，但大小不变的增量大小。默认情况下，SQLServer的具有基于％大小的增量。使此增量不够大。同样这是一个试错的过程。
3. 检查文件系统（S），其中log文件（S）被置于有足够的自由空间。你不想支离破碎的日志文件，你绝对不想在高峰期的工作量数据库中断。
4. 最后但是同样重要的。检查打开的事务时，您的日志文件是意外大。我将在下面展开这个话题。

DBCC OPENTRAN

如果日志大，不能收缩 - 这意味着你有很多开放的交易数据。

与DBCC OPENTRAN检查

仔细地看。

你可以找出问题的根源 - 程序/客户端打开的事务，作出了很多修改，然后永远commits / rollbacks他们。

记住登录线性增长，一个“坏”的事务可以防止日志空间重用（太缩小）

找到这样的罪犯，找到程序员/谁开这样的交易，如最后一个小节用户 - 杀死他们。

澄清：

我的意思是kill在T-SQL kill

我有强烈的怀疑，不是封闭的交易是你的情况。

告知你的进步。

祝好运！