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