主页 / dba / 问题 / 94165
Accepted
Reaces
Asked: 2015-03-03 04:37:26 +0800 CST

Tempdb 正在增长，但是它有很多可用空间

  • 772

在专用于 Dynamics CRM 数据库的 sql 服务器上，我看到了一些奇怪的行为。

在使用以下查询作为基础监控增长时，我注意到 tempdb 在过去几个小时内增长非常频繁：

DECLARE @path NVARCHAR(1000)
SELECT @path = Substring(PATH, 1, Len(PATH) - Charindex('\', Reverse(PATH))) +
                      '\log.trc'
FROM   sys.traces
WHERE  id = 1
SELECT databasename,
       e.name   AS eventname,
       cat.name AS [CategoryName],
       starttime,
       e.category_id,
       loginname,
       loginsid,
       spid,
       hostname,
       applicationname,
       servername,
       textdata,
       objectname,
       eventclass,
       eventsubclass
FROM   ::fn_trace_gettable(@path, 0)
       INNER JOIN sys.trace_events e
         ON eventclass = trace_event_id
       INNER JOIN sys.trace_categories AS cat
         ON e.category_id = cat.category_id
WHERE  e.name IN( 'Data File Auto Grow', 'Log File Auto Grow' )
ORDER  BY starttime DESC

给出数据文件的几行增长：

tempdb  Data File Auto Grow Database    2015-03-02 09:50:33.187 2

但是，当我查看 tempdb 占用的空间时，我没有看到空间紧缩的位置：

USE tempdb 
GO 
SELECT DB_NAME() AS DbName, 
name AS FileName, 
size/128.0 AS CurrentSizeMB,  
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS FreeSpaceMB 
FROM sys.database_files;

给出以下输出：

DbName  FileName    CurrentSizeMB   FreeSpaceMB
tempdb  tempdev     7500.000000     7492.625000
tempdb  templog     156.132812      93.820312
tempdb  tempdev2    7250.000000     7245.625000
tempdb  tempdev3    7250.000000     7245.312500
tempdb  tempdev4    7366.500000     7360.875000

维护 CRM 的人要求我们缩小 tempdb。
我的同事过去曾有义务。但是我不愿意在没有解释的情况下这样做。尤其是考虑到收缩已经成为几乎每周都会发生的事情。

谁能告诉我为什么 tempdb 有这么多增长事件，以及如何正确处理？
我目前正在考虑要求更多存储空间，并将 tempdb 驱动器增加 50%。
然而，这感觉就像治疗症状，而不是原因。

sql-server sql-server-2008-r2

3 个回答

  1. 这是一个老问题，但看起来它应该得到一个更普遍的答案。

    关于 SQL Server 上 tempdb 大小的标准建议是使其足够大以处理服务器向其抛出的任何常规活动，并停止对增长和收缩进行微观管理。

    SQL 使用 tempdb 处理大量内容：内存排序、表重新索引、显式创建的临时表、数据库快照等。SQL 应根据需要使用 tempdb 中的空间，并在完成后在内部释放它。整体文件大小不应该一直改变。零理由继续将该空间回收回操作系统，SQL 可能很快会再次需要它。确定 tempdb 使用量是否“正常”的唯一方法是随着时间的推移对其进行监控。

    作为生产 DBA，我会拒绝应用程序团队提出的缩减 tempdb 的请求，至少无需进行大量进一步讨论。这也适用于“供应商建议”；即使供应商是 Microsoft - MS CRM 团队（以及 SharePoint 团队和 System Center 团队等）也不是 Microsoft SQL 产品团队。

    您的帖子没有说明您的用户数据库有多大，但根据我作为生产 DBA 的经验，30GB 的 tempdb 数据文件一点也不大。事实上，如果您仍然看到 tempdb 数据文件增长到 30GB，那么与他们的要求相反，您需要使其更大，而不是更小。如果您的用户数据库非常大（100 GB 或 TB），则 100 GB 或更大的 Tempdb 大小并不少见。

    为 SQL 提供完成其工作所需的磁盘空间。

    另一方面，您的 tempdb日志文件非常小。在您的情况下，我可能会将其设为数据文件总大小的 25% 或更多。

    综上所述，在您的情况下，我可能会尝试以下操作：

    • 4 个数据文件，每个 20GB 大小。1GB的增长率。
    • 1x 日志文件，20GB 大小，4GB 增长率。

    继续监控，看看这是否足够大，或者它们是否继续增长。

    有一些活动（写得不好的查询、重新索引大表等）可能会破坏日志，并且需要更有针对性地关注到底是什么导致了问题。

    • 3
  2. Best Answer

    TempDB 文件的自动增长模型是什么？微小的增量会导致许多小的自动增长，而大的增量会导致更少但更密集的增长例程。

    大概是因为在服务器上运行的查询正在构造大量临时表、表变量或游标等，所以 TempDB 正在增长？

    是否知道正在运行哪些查询，是否有历史基线来比较自动增长和大小？

    如果事情突然发生了变化，并且组织没有显着增加它使用的实际数据量，我猜想开发人员或报告用户已经改变了他们运行查询的方式。

    关于上述内容，我认为我们需要您提供更多信息。

    • 2

  3. 虽然我遇到了同样的问题，但我遇到了不同的解决方案。

    问题： tempdb 数据文件位于 99% 的未使用空间。磁盘空间接近于零。我在磁盘上释放了一些空间，在 24 小时内数据文件已经增长到再次消耗所有磁盘空间。他们仍然报告 99% 的未使用空间。

    解决方案： 我们让 checkDB 每天晚上在一个作业中运行。checkDB 在 tempdb 中创建了一个快照，该快照对于 tempdb 来说太大而无法处理并一直失败（我们也试图单独解决作业失败的原因）。事实证明，这两个问题是相互关联的，tempdb 数据文件被填充并随着 checkDB 作业自动增长，这会因为磁盘空间不足而失败。正在检查的数据库超过 TB。

    希望这会为未来的 Google 员工增加上述解决方案。

    • 2

相关问题