为什么我的tempdb填满了，什么是想缩小它？

经过几个月的完全平坦的磁盘使用情况，我的tempdb文件在周末突然增长了几个演出。公司里没有人知道可能发生了什么变化。

当我检查tempdb数据库时，它只有一些非常小的表，其名称是hex数字的string。

在寻找原因时，我发现以下消息在事件日志中每隔几分钟重复几天：

DBCC SHRINKDATABASE for database ID 2 is waiting for the snapshot transaction with timestamp 51743762409 and other snapshot transactions linked to timestamp 51743762409 or with timestamps older than 51801253540 to finish.

我找不到DBCC SHRINKDATABASE可能由tempdb上的任何人运行（DB ID为2）的任何可能的方法。微软自己的文档说，SHRINKDATABASE不应该在tempdb在线时运行，所以我无法想象SQL server本身正在运行它。

我试图弄清楚：

什么可能导致tempdb文件突然快速增长？我不知道任何使用临时表的代码或在此服务器上声明表variables。还有什么使用tempdb文件？
为什么DBCC SHRINKDATABASE在tempdb上运行，为什么它失败？

首先，我会检查默认跟踪，如果有人手动运行DBCC SHRINKDATABASE命令。以下代码将帮助您在默认跟踪中审计DBCC stmt。你可以分享你的SELECT @@ VERSION吗？

 DECLARE @filename VARCHAR(255) SELECT @FileName = SUBSTRING(path, 0, LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc' FROM sys.traces WHERE is_default = 1; SELECT gt.HostName, gt.ApplicationName, gt.NTUserName, gt.NTDomainName, gt.LoginName, gt.SPID, gt.EventClass, te.Name AS EventName, gt.EventSubClass, gt.TEXTData, gt.StartTime, gt.EndTime, gt.ObjectName, gt.DatabaseName, gt.FileName, gt.IsSystem FROM [fn_trace_gettable](@filename, DEFAULT) gt JOIN sys.trace_events te ON gt.EventClass = te.trace_event_id WHERE EventClass in (116) --AND gt.EventSubClass = 2 ORDER BY StartTime DESC;

如果最近数据和日志文件增长，下面会给你，可以帮助确定为什么？

 DECLARE @filename VARCHAR(255) SELECT @FileName = SUBSTRING(path, 0, LEN(path)-CHARINDEX('\', REVERSE(path))+1) + '\Log.trc' FROM sys.traces WHERE is_default = 1; --Check if the data and log files auto-growed. Look for tempdb, log files etc. SELECT gt.ServerName , gt.DatabaseName , gt.TextData , gt.StartTime , gt.Success , gt.HostName , gt.NTUserName , gt.NTDomainName , gt.ApplicationName , gt.LoginName FROM [fn_trace_gettable](@filename, DEFAULT) gt JOIN sys.trace_events te ON gt.EventClass = te.trace_event_id WHERE EventClass in ( 92, 93 ) --'Data File Auto Grow', 'Log File Auto Grow' ORDER BY StartTime; --

检查你的维修计划。有人可能已经手动更改或添加一个到服务器。同时检查你的数据库的恢复模式是否最近改变了。