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