我安装了 SQL 2005，我的 templog.ldf 文件不断增大，占用了所在驱动器上的所有可用空间。有时它会在剩余几 MB 空间时停止，但有时会进一步增大，这是 c 驱动器，我认为这种行为可能与我见过的其他一些问题有关。
我的问题是，我该怎么办，我可以将日志移动到另一个驱动器，但我有理由假设它不会在那里做同样的事情。我假设这种行为可能是由于我可以更改某些内容而导致的，并且 45gb 对于 tempdb 日志来说是一个不寻常的大小。我们的代码中确实使用了很多临时表和表值函数，因此有足够的空间使用 tempdb，我可以理解 tempdb 数据库的增长，但不明白 templog 增长的原因。
到目前为止，我已经运行了 DBCC OPENTRAN('tempdb') 来查看是否有任何旧事务悬而未决，但事实并非如此。我读过有关如何缩小 tempdb 的文章，并且已经这样做了几次，但我真的很想知道我能做些什么来阻止这种情况的发生，或者更详细地了解它为什么会增长这么多。
==编辑==
1）tempdb 使用简单恢复模型
2）templog 的增长发生在早上的几个小时内，当时我们正在运行一些预定的查询，基本上是前一天办公时间之外的大量报告。在此期间，文件的大小稳步增长。我们控制同时运行的并发报告数量，增加并发报告的数量会增加日志的增长速度。
答案1
检查您的报告查询。其中是否有包含 DISTINCT 的查询？其中是否有笛卡尔连接？
是否有任何报告查询将链接服务器作为连接的成员进行访问？如果是，这可能会导致 tempdb 日志和数据库增长。
当早上运行报告时，其中任何一个都会崩溃吗？
答案2
我们遇到了类似的问题，在向 Microsoft 提出 PSS 呼叫并深入调查该问题后，我们确定了以下可能的原因和解决方案。
原因：
导致这些症状的可能原因是放置用户数据库的磁盘/LUN 存在严重的 I/O 响应问题；这导致用户数据库上的自动检查点需要很长时间才能完成。
现在，只有当 tempdb 日志已满 70% 时才会对 tempdb 执行检查点，而且它的优先级低于用户数据库检查点。因此，当对用户数据库发出自动检查点并尝试完成时，由于 tempdb 使用率过高，导致 tempdb 日志文件很快填满；当日志使用率为 70% 时，tempdb 检查点会发生，但会排在用户数据库检查点后面。
在用户数据库检查点完成的时间内，tempdb 日志文件不断被填满，如果设置了自动增长，日志文件在需要更多空间时就会增长。这就是日志文件不断增长的原因。
总之，您描述的症状的最可能根本原因是由于用户和/或 tempdb 数据库/日志文件的磁盘/lun 的 I/O 响应不佳。
解决方案：
我们在整理 I/O 子系统时解决了这个问题，方法是设置一个警报，当 tempdb 日志文件已满 75% 时触发该警报，并作为响应执行一项强制手动“检查点”（优先于自动系统检查点）的作业，清除 tempdb 日志，防止其无限期地自动增长。为应对任何其他可能发生的情况，让日志文件保持自动增长仍然是一个好主意。此外，我强烈建议您在修复后考虑根据您的环境将 tempdb 日志文件大小减小到有意义的大小。
希望这可以帮助。
答案3
临时数据库上的恢复模式设置成什么？如果没有设置为简单，则将其设置为简单。这应该可以防止其增长。如果已经设置为简单，那么我认为存在一个需要解决的潜在问题，任何缩小文件的尝试都只是治标不治本。
答案4
这很可能是由失控的 Cross Join 查询引起的。最好的办法是使用 Profiler 找到它，然后修复它。
另一种查找方法是限制 TempDB 日志文件的大小，然后等待查看哪些查询失败。不过，我敢打赌，已经失败了，却没人告诉你。