重启服务当然TEMPDB可以恢复到初始状态，暂时解决问题。但日志文件的异常增长还是会发生。
想知道日志异常增长的原因在哪？想求一个永久的解决办法。
注：我也看了网上一些解决TEMPDB的方法，比如收缩数据库，但我想这也只是暂时缓解的方法。
还有给TEMPDB添加一个数据库文件，但由于这个服务器比较早其他磁盘也并不富裕。担心依旧经受不了日志文件的突然增长。
而且发现仅仅是TEMPDB的日志文件增长很快，mdf文件并没有明显的增长，不知道这种情况一般是什么操作造成的。
这个库运行了多年一直没有这样的问题，只是最近对库表和存储过程进行了一些升级（由于升级不是我参与的，具体内容还不知道），就突然出现这个问题。
希望各位高手给点指导！急！
8 个解决方案
#1
补充一点：是不是不应该限制住TEMPDB的空间。这样反而不好。但是一下子占几个G又太不正常了。
#2
---参考:
SQL Server会自动创建一个名为tempdb的数据库作为工作空间使用，当您在存储过程中创建一个临时表格时，比如(CREATE TABLE #MyTemp)，无论您正在使用哪个数据库，SQL数据库引擎都会将这个表格创建在tempdb数据库中。
SQL Server会自动创建一个名为tempdb的数据库作为工作空间使用，当您在存储过程中创建一个临时表格时，比如(CREATE TABLE #MyTemp)，无论您正在使用哪个数据库，SQL数据库引擎都会将这个表格创建在tempdb数据库中。
而且，当您对大型的结果集进行排序，比如使用ORDER BY或GROUP BY或UNION或执行一个嵌套的SELECT时，如果数据量超过了系统内存容量，SQL数据库引擎就会在tempdb中创建工作表格。在您运行DBCC REINDEX或者向现有的表格中添加集群序列时， SQL数据库引擎同样会使用tempdb。实际上，任何针对大型表格的ALTER TABLE命令都会在tempdb中吃掉大量的磁盘空间。
在理想状态下，SQL会在完成指定操作后自动清理，并销毁这些临时表格，但是，很多问题都会导致错误。比如，您的代码创建了一个事务，但是却没能执行或重新运行，那么这些孤儿对象将遗留在tempdb中。而且，对大型数据库运行DBCC CHECK时，它还会消耗掉大量的空间，您往往会发现tempdb比设想的要大很多，甚至还会收到SQL即将用完磁盘空间的出错信息。
您有很多方法可以来修正这一情况，但从长远看来，您需要执行其它的步骤来保证正常使用。
为tempdb“减肥”最简单的办法就是关闭SQL数据库引擎然后重新启动，但是在重要的任务中，这样做可能难度很大；另一方面，如果您已经处于无法承受的状态，那么我的建议就是将这个坏消息告知您的上司，然后开始操作。
如果您幸运拥有另外一块磁盘可以用来放置tempdb，可以进行如下的操作：
USE master
GO
ALTER DATABASE tempdb modify file (name = tempdev, filename = NewDrive:Pathtempdb.mdf )
GO
ALTER DATABASE tempdb modify file (name = templog, filename = NewDrive:Pathtemplog.ldf )
GO
还有三项关于tempdb的属性应该检查：自动增长标记，初始大小和恢复模式，以下是关于这些属性的小窍门：
自动增长标记：记住将这个标记设为True。
初始大小：tempdb的初始大小要根据常用的工作负载来设定，如果有很多用户在使用GROUP BY、ORDER BY或者对大型表格进行聚合操作，那么您的常用工作负载会相当大。如果服务器脱机时，您可能需要检查日志文件与数据文件是否位于同一磁盘，如果这样的话，应当将需要将它们转移到新的磁盘上，您只需指明相应的数据库并使用相同的命令即可。
恢复模式：将恢复模式设定为True意味着让SQL自动截去tempdb的日志文件（在使用了每个表格之后），要找出tempdb所使用的恢复模式，可以使用如下命令：
SELECT DATABASEPROPERTYEX( tempdb , recovery )
恢复模式有三种选择：简单、完整或大量记录（bulk-logged），如要改变设置，可以使用以下命令：
ALTER DATABASE tempdb SET RECOVERY SIMPLE
这些步骤可以优化您系统中使用的tempdb，除了解决磁盘空间问题外，您还会发现SQL Server系统性能的提升。
#3
告诉你限制大小或重启是对你不负责，
建议你通过sys.dm_db_session_space_usage等动态管理视图直接跟踪出批处理SQL及对应分配与取消的总页数，从而确定是何原因引起的。
如果分配的页远远大于释放了页，那么对应的批处理就是问题所在。
建议你通过sys.dm_db_session_space_usage等动态管理视图直接跟踪出批处理SQL及对应分配与取消的总页数，从而确定是何原因引起的。
如果分配的页远远大于释放了页，那么对应的批处理就是问题所在。
#4
2楼的那段话，我也见过，就是在弄一个文件组放到其他盘。 而且我的库revoery模式是simple了。
3楼dm_db_session_space_usage这个DMV是很好使，但我的印象中是不是这个是SQL SERVER 2005才有的，我这个库是SQL SERVER 2000是不是用不了。
3楼dm_db_session_space_usage这个DMV是很好使，但我的印象中是不是这个是SQL SERVER 2005才有的，我这个库是SQL SERVER 2000是不是用不了。
#5
改程序！
#6
监控一下喽
有偿支持
有偿支持
#7
手动设置checkpoint看看
#8
应该是查询中临时表多了，最好将tempdb数据库弄大些，这样不至于因为扩容写日志文件。
将可能会扩大tempdb空间的操作找出来。
将可能会扩大tempdb空间的操作找出来。
#1
补充一点：是不是不应该限制住TEMPDB的空间。这样反而不好。但是一下子占几个G又太不正常了。
#2
---参考:
SQL Server会自动创建一个名为tempdb的数据库作为工作空间使用，当您在存储过程中创建一个临时表格时，比如(CREATE TABLE #MyTemp)，无论您正在使用哪个数据库，SQL数据库引擎都会将这个表格创建在tempdb数据库中。
SQL Server会自动创建一个名为tempdb的数据库作为工作空间使用，当您在存储过程中创建一个临时表格时，比如(CREATE TABLE #MyTemp)，无论您正在使用哪个数据库，SQL数据库引擎都会将这个表格创建在tempdb数据库中。
而且，当您对大型的结果集进行排序，比如使用ORDER BY或GROUP BY或UNION或执行一个嵌套的SELECT时，如果数据量超过了系统内存容量，SQL数据库引擎就会在tempdb中创建工作表格。在您运行DBCC REINDEX或者向现有的表格中添加集群序列时， SQL数据库引擎同样会使用tempdb。实际上，任何针对大型表格的ALTER TABLE命令都会在tempdb中吃掉大量的磁盘空间。
在理想状态下，SQL会在完成指定操作后自动清理，并销毁这些临时表格，但是，很多问题都会导致错误。比如，您的代码创建了一个事务，但是却没能执行或重新运行，那么这些孤儿对象将遗留在tempdb中。而且，对大型数据库运行DBCC CHECK时，它还会消耗掉大量的空间，您往往会发现tempdb比设想的要大很多，甚至还会收到SQL即将用完磁盘空间的出错信息。
您有很多方法可以来修正这一情况，但从长远看来，您需要执行其它的步骤来保证正常使用。
为tempdb“减肥”最简单的办法就是关闭SQL数据库引擎然后重新启动，但是在重要的任务中，这样做可能难度很大；另一方面，如果您已经处于无法承受的状态，那么我的建议就是将这个坏消息告知您的上司，然后开始操作。
如果您幸运拥有另外一块磁盘可以用来放置tempdb，可以进行如下的操作：
USE master
GO
ALTER DATABASE tempdb modify file (name = tempdev, filename = NewDrive:Pathtempdb.mdf )
GO
ALTER DATABASE tempdb modify file (name = templog, filename = NewDrive:Pathtemplog.ldf )
GO
还有三项关于tempdb的属性应该检查：自动增长标记，初始大小和恢复模式，以下是关于这些属性的小窍门：
自动增长标记：记住将这个标记设为True。
初始大小：tempdb的初始大小要根据常用的工作负载来设定，如果有很多用户在使用GROUP BY、ORDER BY或者对大型表格进行聚合操作，那么您的常用工作负载会相当大。如果服务器脱机时，您可能需要检查日志文件与数据文件是否位于同一磁盘，如果这样的话，应当将需要将它们转移到新的磁盘上，您只需指明相应的数据库并使用相同的命令即可。
恢复模式：将恢复模式设定为True意味着让SQL自动截去tempdb的日志文件（在使用了每个表格之后），要找出tempdb所使用的恢复模式，可以使用如下命令：
SELECT DATABASEPROPERTYEX( tempdb , recovery )
恢复模式有三种选择：简单、完整或大量记录（bulk-logged），如要改变设置，可以使用以下命令：
ALTER DATABASE tempdb SET RECOVERY SIMPLE
这些步骤可以优化您系统中使用的tempdb，除了解决磁盘空间问题外，您还会发现SQL Server系统性能的提升。
#3
告诉你限制大小或重启是对你不负责，
建议你通过sys.dm_db_session_space_usage等动态管理视图直接跟踪出批处理SQL及对应分配与取消的总页数，从而确定是何原因引起的。
如果分配的页远远大于释放了页，那么对应的批处理就是问题所在。
建议你通过sys.dm_db_session_space_usage等动态管理视图直接跟踪出批处理SQL及对应分配与取消的总页数，从而确定是何原因引起的。
如果分配的页远远大于释放了页，那么对应的批处理就是问题所在。
#4
2楼的那段话，我也见过，就是在弄一个文件组放到其他盘。 而且我的库revoery模式是simple了。
3楼dm_db_session_space_usage这个DMV是很好使，但我的印象中是不是这个是SQL SERVER 2005才有的，我这个库是SQL SERVER 2000是不是用不了。
3楼dm_db_session_space_usage这个DMV是很好使，但我的印象中是不是这个是SQL SERVER 2005才有的，我这个库是SQL SERVER 2000是不是用不了。
#5
改程序！
#6
监控一下喽
有偿支持
有偿支持
#7
手动设置checkpoint看看
#8
应该是查询中临时表多了，最好将tempdb数据库弄大些，这样不至于因为扩容写日志文件。
将可能会扩大tempdb空间的操作找出来。
将可能会扩大tempdb空间的操作找出来。