我安装了 SQL 2005，并且我的 templog.ldf 文件不断增长，以消耗它所在驱动器上的所有可用空间。有时它会停止几mb，但有时它会更进一步，这是c驱动器，我认为这种行为可能与我看到的其他一些问题有关。
我的问题是，我应该怎么做，我可以将日志移动到另一个驱动器，但我有理由假设它不会在那里做同样的事情。我假设这种行为可能是我可以更改的结果，并且 45gb 对于 tempdb 日志来说是一个不寻常的大小。我们在代码中确实使用了很多临时表和表值函数，因此使用 tempdb 的空间很大，我可以理解 tempdb 数据库的增长，但不明白 templog 增长的原因。
到目前为止，我已经运行了 DBCC OPENTRAN('tempdb') 来查看是否有任何旧事务在附近，它们不是。我已经阅读了有关如何缩小 tempdb 并已经这样做了几次，但我真的想知道如果我能做些什么来阻止这种情况的发生，或者更多关于它为什么会增长如此之多的详细信息第一名。
==编辑==
1) tempdb 使用简单的恢复模型
2) templog 的增长发生在早上几个小时内，当时我们有一些预定的查询正在运行，基本上是前一天办公时间用完的报告负载。文件的大小在这段时间内稳步增长。我们控制同时运行多少并发报告，增加并发报告的数量会增加日志的增长速度。
我们遇到了类似的问题，在向 Microsoft 提出 PSS 电话并深入调查该问题后，我们将其划分为以下可能的原因和解决方案。
原因：
出现这些症状的可能原因是放置用户数据库的磁盘/lun 存在严重的 I/O 响应问题；这会导致用户数据库上的自动检查点需要很长时间才能完成。
现在，tempdb 上的检查点仅在 tempdb 日志已满 70% 时才会出现，并且它的优先级低于用户数据库检查点。因此，当用户数据库上的自动检查点发出并试图完成时，由于 tempdb 的大量使用导致 tempdb 日志文件快速填满；在 70% 的日志使用率时，临时数据库检查点出现，但在用户数据库检查点之后排队。
在用户数据库检查点完成的时间内，tempdb 日志文件不断被填满，如果设置了 autogrow，则日志文件在需要更多空间时会增长。这就是日志文件不断增长的原因。
总之，您描述的症状最可能的根本原因是由于您的用户和/或 tempdb 数据库/日志文件的磁盘/lun 的 I/O 响应不佳。
解决方案：
我们在整理 I/O 子系统时解决了这个问题，方法是设置一个警报，该警报在 tempdb 日志文件已满 75% 时触发，并作为响应执行一项强制手动“检查点”的作业（优先于自动系统检查点），清除 tempdb 日志以防止它无限期地自动增长。将日志文件保留为自动增长以应对任何其他可能性仍然是一个好主意。此外，我强烈建议您在安装修复程序后考虑根据您的环境将 tempdb 日志文件的大小减小到有意义的大小。
希望这可以帮助。
检查您的报告查询。你有什么有区别的吗？他们中的任何一个都有笛卡尔连接吗？
是否有任何报告查询以联接成员的身份访问链接服务器？如果是这样，这可能会导致 tempdb 日志和数据库增长。
当报告在早上运行时，它们中的任何一个都会崩溃吗？
临时数据库上的恢复模式设置是什么？如果未设置为简单，则将其设置为简单。这应该阻止它增长。如果它已经设置为简单，那么我会说有一个潜在的问题需要解决，任何缩小文件的尝试都只是解决问题的症状，而不是根本原因。
在过去的几个小时里，我一直在阅读和做笔记
http://technet.microsoft.com/en-gb/library/cc966545.aspx
那里有很多细节和解决问题的建议。似乎除非您的 tempdb 正在扩展并且永远不会停止增长，否则它可能只是占用了它需要的空间量，并且最初应该配置为该大小。有一节是关于估计 tempdb 所需的空间以及跟踪可能占用 tempdb 空间的部分。因此，我要做的第一件事就是将 tempdb 移到更大的驱动器上，然后看看会发生什么。
有一个名为“tempdb logging 所需的空间”的部分指示哪些功能使用日志，还有另一个较早的部分详细介绍了使用 tempdb 的功能的超集。
标题为“监控 I/O”的部分有一些关于性能计数器的想法值得关注，快速浏览一下我的服务器，将这些放在你可能遇到的 io-bottleneck 领域。我会监视这些一段时间，看看情况如何。tempdb 日志文件的利用率实际上也低于 50%，这符合它今天早上在负载下扩展的想法，并且此后一直保留该空间。
我会在它成长到的大小是它需要的大小的基础上继续前进，在未来监控这个大小，并确保它在任何驱动器上都有增长空间。正如这里的一些人所建议的那样，我将查看临时日志扩展时正在执行的操作，看看是否可以在其中进行任何调整。我还将密切关注那些 io 性能计数器，看看是否需要处理一些事情。
还有另外一个有趣的部分，标题为“升级到 SQL Server 2005”，它表明 tempdb 在 2005 年用于比 2000 年更多的事情（包括新功能和以前不使用 tempdb 的现有功能）。我最近才升级到 2005，所以这可能是这突然成为问题的部分原因。不过，我不记得在其他任何地方看到过关于升级到 2005 的内容，这有点痛苦。
一些 SQL 查询或存储过程正在做坏事——你唯一能做的就是分析 tempdb 以捕获“数据库：日志文件自动增长”事件，当这种情况发生时，使用分析器和查询像 sysprocesses 这样的表来查找找出糟糕的过程是什么。
不幸的是，追踪流氓过程的方法是老式的侦探工作。
您是否尝试过使用 DBCC SHRINKFILE() 调整 tempdb 日志文件的大小？如果是这样，从 [非常小的值] 到 45GB 或更多需要多长时间？
这很可能是由失控的交叉连接查询引起的。最好的办法是使用 Profiler 找到它，然后修复它。
找到它的另一种方法是限制 TempDB 日志文件的大小，然后等待查看哪个查询失败。但是，我敢打赌它已经失败了，没有人告诉你。
如果重新启动 SQL 引擎，文件将设置为初始大小。您应该在所有自动增长文件上设置最大大小。