我正在调查一个问题，我的 tempdb 日志文件的增长超出了任何看似合理的比例。今天早上，它的大小是数据文件的 10 倍多。然而，数据库继续正常运行，templog 大小的唯一限制似乎是它所在的磁盘的大小。
那么我的问题是，限制 templog 的大小是否安全？我听说不应该限制 tempdb 的大小，因为它对于需要在 sql server 中完成的工作至关重要。但是，日志文件刚好增长到磁盘允许的大小这一事实表明我可以限制它而不会破坏任何东西。是这样吗？如果是这样，是否有一个下限（即数据文件的总大小）我不应该将其限制在下面？
顺便说一句，我意识到这不是解决日志增长问题的办法，该问题正在调查中但可能不会很快得到解决。
干杯，
答案1
通过限制日志的大小，你所做的就是在以下情况下导致失败：无论是什么在增长达到限制。（将出错并且可能回滚事务）。
实际上，这可能是一种有用的方法来查看是什么让日志变得如此之大！:) 虽然甚至更好方法是使用 Perfmon 监视 SQL:Database:Log Used (kb) 计数器来查看什么时候它正在增长，并将其与服务器上的其他活动关联起来。
答案2
我们遇到了类似的问题，在向 Microsoft 提出 PSS 呼叫并深入调查该问题后，我们确定了以下可能的原因和解决方案。
原因：
导致这些症状的可能原因是放置用户数据库的磁盘/LUN 存在严重的 I/O 响应问题；这导致用户数据库上的自动检查点需要很长时间才能完成。
现在，只有当 tempdb 日志已满 70% 时才会对 tempdb 执行检查点，而且它的优先级低于用户数据库检查点。因此，当对用户数据库发出自动检查点并尝试完成时，由于 tempdb 使用率过高，导致 tempdb 日志文件很快填满；当日志使用率为 70% 时，tempdb 检查点会发生，但会排在用户数据库检查点后面。
在用户数据库检查点完成的时间内，tempdb 日志文件不断被填满，如果设置了自动增长，日志文件在需要更多空间时就会增长。这就是日志文件不断增长的原因。
总之，您描述的症状的最可能根本原因是由于用户和/或 tempdb 数据库/日志文件的磁盘/lun 的 I/O 响应不佳。
解决方案：
我们在整理 I/O 子系统时解决了这个问题，方法是设置一个警报，当 tempdb 日志文件已满 75% 时触发该警报，并作为响应执行一项强制手动“检查点”（优先于自动系统检查点）的作业，清除 tempdb 日志，防止其无限期地自动增长。为应对任何其他可能发生的情况，将日志文件保留为自动增长仍然是一个好主意。
希望这可以帮助。