我的templog.ldf很大（45gb），该怎么办？

我已经安装了SQL 2005，并且templog.ldf文件不断增长，以占用其所在驱动器上的所有可用空间。有时它会以几MB的可用空间停止播放，但有时会更进一步，这是c驱动器，我认为这种行为可能与我所看到的其他问题有关。

我的问题是，我应该怎么做，我可以将日志移到另一个驱动器，但是我有理由认为它不会在那里做同样的事情。我假设这种行为很可能是由于我可以更改的结果，并且tempdb日志无法达到45gb的大小。我们在代码中确实使用了许多临时表和表值函数，因此有很多使用tempdb的范围，我可以理解tempdb数据库的增长，但不了解templog增长的原因。

到目前为止，我已经运行DBCC OPENTRAN（'tempdb'）来查看是否有旧事务在徘徊，但不是。我已经读过有关如何缩小tempdb的信息，并且已经做了几次，但是我真的很想知道我是否可以做些什么来阻止这种情况的发生呢？第一名。

==编辑==

1） tempdb使用简单的恢复模型

2） templog的增长发生在早晨几个小时，这是因为我们有一些计划的查询在运行，基本上是报告的负载，前一天的工作时间都用完了。文件的大小在这段时间内稳定增长。我们控制同时运行多少个并发报告，增加并发报告的数量可以提高日志的增长速度。

检查您的报告查询。您是否有任何DISTINCT？他们中的任何一个都有笛卡尔联接吗？

是否有任何报告查询以联接成员的身份访问链接的服务器？如果是这样，这可能会导致tempdb日志和数据库增长。

当报告在早上运行时，是否有任何崩溃？

在与Microsoft进行PSS呼叫并对该问题进行了深入调查之后，我们遇到了类似的问题，并分为以下可能的原因和解决方案。

原因：

出现该症状的可能原因是由于放置用户数据库的磁盘/ lun出现严重的I / O响应问题；这将导致用户数据库上的自动检查点花费很长时间才能完成。

现在，仅当tempdb日志已满70％并且其优先级低于用户数据库检查点时，才会在tempdb上发生检查点。因此，有效地发布用户数据库上的自动检查点并尝试完成时，由于大量的tempdb使用，会导致tempdb日志文件快速填充；在日志使用率达到70％的情况下，会发生tempdb检查点，但在用户数据库检查点后面排队。

在用户数据库检查点完成的时间中，tempdb日志文件不断填充，如果设置了自动增长，则日志文件将在需要更多空间时增长。这就是日志文件持续增长的原因。

总之，您描述的症状的最可能的根本原因是由于用户和/或tempdb数据库/日志文件的磁盘/ lun的I / O响应不良。

解：

我们通过设置警报来解决I / O子系统的问题，方法是设置警报，当tempdb日志文件变为75％满时触发该警报，并作为响应执行一项工作，该工作强制执行手动“ CHECKPOINT”（优先于自动系统）检查点），清除tempdb日志以防止其无限期自动增长。最好让日志文件保持自动增长，以防其他情况发生。另外，强烈建议您考虑在安装此修补程序后，根据您的环境将tempdb日志文件的大小减小到有意义的程度。

希望这可以帮助。

恢复数据库在temp db上设置了什么？如果未设置为简单，则将其设置为简单。这应该阻止它增长。如果已经将其设置为“简单”，那么我想说有一个潜在的问题需要解决，并且任何缩小文件的尝试都只是在解决问题的症状，而不是根本原因。

我花了最后几个小时阅读并做笔记

http://technet.microsoft.com/zh-CN/library/cc966545.aspx

那里有很多细节和解决问题的建议。看起来，除非您的tempdb正在扩展并且永不停止增长，否则可能只是占用了所需的空间，并且最初应该将其配置为该大小。有一节介绍了估算tempdb所需的空间以及跟踪tempdb中可能占用的空间的部分。因此，我要做的第一件事是将tempdb移动到更大的驱动器上，然后看那里发生了什么。

有一个标题为“ tempdb记录所需的空间”的节指出了哪些功能使用了日志，还有一个较早的节详细介绍了使用tempdb的功能的超集。

标题为“监视I / O”的部分提供了一些有关性能计数器的想法，快速浏览一下我的服务器，可能会遇到一些瓶颈。我将对其进行一段时间的监视，并查看结果如何。实际上，tempdb日志文件的利用率还不到50％，这符合它今天早晨在负载下扩展并从那时起保留了该空间的想法。

我的依据是，它增长到的大小就是所需的大小，在将来监视该大小，并确保无论使用哪种驱动器，都有增长的空间。正如一些人的建议，我将研究临时日志扩展时正在执行的操作，并查看其中是否可以进行任何调整。我还将密切关注那些io性能计数器，以查看是否需要处理某些事情。

另外还有一个有趣的标题为“升级到SQL Server 2005”的部分，该部分表明tempdb在2005年使用的功能比2000年更多（包括新功能和以前不使用tempdb的现有功能）。我最近才升级到2005，所以这可能是突然成为问题的部分原因。我不记得在升级到2005时在其他任何地方看到过这种情况，这有点痛苦。

这很可能是由于交叉联接查询失控造成的。最好的选择是使用Profiler来找到它，然后修复它。

查找它的另一种方法是限制TempDB日志文件的大小，然后等待以查看查询失败。但是，我敢打赌，它已经失败了，没有人告诉你。

如果重新启动SQL引擎，则文件将设置为初始大小。您应该在所有自动增长文件上放置一个最大大小。

某些SQL查询或存储的proc做的不好-唯一可以做的就是配置tempdb以捕获“数据库：日志文件自动增长”事件，然后在发生这种情况时，使用配置文件和针对sysprocesses等表的查询来查找找出错误的过程是什么。

不幸的是，这要依靠老式的侦探工作来追踪流氓程序。

您是否尝试过使用DBCC SHRINKFILE（）调整tempdb日志文件的大小？如果是这样，从[非常小的值]到45GB或更多需要多长时间？