SQL Server 日志文件自动收缩答案

【问题标题】：SQL Server log file autoshrinkSQL Server 日志文件自动收缩
【发布时间】：2019-02-02 16:01:51
【问题描述】：

我的数据库处于简单恢复模式，我预计日志文件不会呈指数级增长，但是日志文件大小正在变大。

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

自动收缩会影响简单恢复模式下的应用程序性能吗？ 50GB 阈值是个好阈值吗？

谢谢！

【问题讨论】：

“变大”是什么意思？ SIMPLE 恢复模型中的日志大小将反映正在进行的操作所需的空间，因此如果它只会再次增长（这会降低性能），则不应缩小。如果您有一个一次性操作导致日志大小增加并且不会再次发生，请执行一次性收缩以回收空间。
日志文件大小再次增长到近 200GB，即使在 SQL 管理员缩小后也是如此。我从您的评论中了解到自动收缩可能会影响性能，还有其他方法可以限制日志文件的大小吗？顺便说一句，该应用程序每分钟写入数千笔交易。
我的评论主要是关于自动增长影响性能，当需要更多空间时，这将是自动收缩后的结果。日志正在增长是有原因的。 SELECT log_reuse_wait_desc FROM sys.databases 显示什么？
是的，您可以限制日志文件的大小。但是当达到该限制时，您的数据库将停止运行并需要管理员来缩小文件。既然“autoshrink”做到了它所说的，那么大尺寸肯定是有原因的。每分钟有数千个事务，可能需要这个大小。如果这些交易对您的公司有任何价值，您可能不应该使用简单的恢复模式，而是增加磁盘空间。

【解决方案1】：

来自您的评论：

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

我可以假设您的数据库不是 autoshrink 的好候选者（从我的实践来看，autoshrink 是一个很好的解决方案分贝）。

如果日志很大并且无法缩小 - 这意味着您在打开的事务中有大量数据。

仔细看。

你可以找到罪魁祸首——打开事务的程序/客户端，进行大量修改，然后永远不要commits/rollbacks 他们。

请记住，日志是线性增长的，一个“坏”事务可能会阻止日志空间重用（并且还会缩小）

找到这样的罪魁祸首，找到打开此类交易的程序员/用户，作为最后的措施 - 杀死他们。

澄清：

我的意思是 kill 在 T-SQL 中 kill

我强烈怀疑未完成的交易就是你的情况。

告知您的进度。

祝你好运！

【讨论】：