Sql server 将ldf文件的大小保持在一定的限制范围内

我有一个场景，SQL Server上的ldf文件在4-5天内增长到超过30GB。由于这会带来潜在的空间问题（硬盘容量略高于250GB），我搜索了一些解决方案，但却感到困惑，因为我在缩小ldf文件时发现的任何东西都表明它将再次增长。一个解决方案是定期执行此操作，但我不确定它是否有长期帮助。是否可能以某种方式固定ldf文件的最大大小，然后SQL Server会自动删除其中的旧记录

如果这听起来不太好，请分享一些我应该如何处理的想法？什么是最好的行动方案

---

提前谢谢

这种情况有两种情况

场景1-数据库处于简单恢复状态，事务日志中有一个很大的进程。在这种情况下，您只能将事务日志保留为最大大小，并尽可能升级驱动器空间

场景2（最有可能）-您的数据库处于完全恢复模式，并且没有配置事务日志备份。一个好的备份实践是每日完整备份（如果数据库不是太大的话）和每小时事务日志备份。在进行了良好的完整备份，然后进行了良好的事务日志备份之后，可以收缩事务日志

以下是一些可能有帮助的代码：

收缩事务日志-

使用了多少事务日志-

USE DatabaseName
GO

DBCC SQLPERF (logspace)

---

如果收缩事务日志后发现文件大小相同，请尝试在事务日志设置中手动调整文件大小。或者，您可以将数据库设置为简单恢复，然后再设置为完全恢复。尽管后者会中断事务日志备份，直到下一次完全备份

您需要查看事务日志备份！数据库采用什么恢复模式？一种是简单恢复模式，另一种是完整恢复模式。哪个LDF文件增长到30GB？无论如何，谢谢你的回答，我也会做类似的事情。我的想法是将日志置于简单恢复模式，然后缩小日志并限制磁盘上文件的最大大小。我的另一个问题是，这会带来一些长期问题吗？我必须补充一点，DB本身仅用作中间件，插入数据库的数据由另一个应用程序处理并存储在完全不同的系统上，该系统由专家维护，因此数据在那里是安全的。因此，听起来数据不需要频繁备份。我认为你的计划很好。但是，请记住，即使数据库处于简单模式，事务仍会写入事务日志。如果有一个较大的进程发生，则在进程完成之前，它不会写入检查点。在写入检查点之前，tlog不会截断。例如，如果我编写一个删除100万行的查询，即使在简单模式下，它也会在检查点出现之前将所有100万行写入事务日志。据我所知，这些数据库上并没有发生如此大的事务，所以我现在看不到潜在的问题。然而，我试图假设，如果执行如此大的事务并为日志文件设置相当高的限制，会造成多大的问题。另外一个问题是，我是否可以计算或至少得到一个事务将占用多少空间的模糊近似值？我想没有简单的公式。你是对的，没有简单的公式。这完全取决于过程。我通常做的是设置日志大小，如果需要，允许它自动增长。大约一个月后，如果你还没有看到你的日志大小增长，那么你应该是好的。如果它真的长大了，那就让它长到什么大小就好了。你不想做的一件事就是让它成长，缩小，让它成长，缩小。这会导致碎片并降低性能。

USE DatabaseName
GO

DBCC SQLPERF (logspace)