Bra*_*adC 5 sql-server-2008 shrink tempdb
因此，理想情况下，您希望适当地预先调整 TempDB 数据和日志文件的大小，以便这不是问题，但有时流氓开发人员会在工作时间内在生产服务器上运行疯狂的大型查询，从而导致 TempDB 数据文件爆炸巨大的。
如果 TempDB 确实是驱动器上唯一的东西，那么我可能就这样保留它，但在某些服务器上，我有几个 SQL 实例，它们都共享同一个 TempDB 驱动器。
那么如何在不重启实例的情况下缩小这些 TempDB 数据文件呢？
我通常会尝试：
DBCC SHRINKFILE (name = 'tempdev', size = 5000)
这在 SQL 2000 和 2005 中相当一致地工作（假设实际的 tempdb 活动已经逐渐减少），但在 2008 年似乎不经常工作（在我当前的服务器上，它只适用于 4 个数据文件中的 1 个，其他人继续保留大 2-3 倍）。
你在这里有两个不同的问题：
Q：有时流氓开发者在工作时间在生产服务器上运行一个疯狂的大查询，导致TempDB数据文件炸毁。
答：当发生这种情况时，所有 TempDB 数据文件将大致相等地增长，因此您不必担心缩小特定文件。坦率地说，您不想缩小它们 - 如果您为 TempDB 预留了驱动器空间，只需将这些文件留在原处。为什么要继续打同样的战斗？几周后，您将有一个流氓开发人员运行另一个查询。把这个留在原地。您不会根据空驱动器空间获得奖励。
现在，话虽如此，如果您将 TempDB 的数据和日志文件与您的用户数据库（或天堂禁止，引导驱动器）放在同一卷上，那么这就是真正的根本原因，您需要解决这个问题。即使您不将它们放在单独的主轴上，TempDB 也应该位于单独的逻辑卷上以缓解这个确切的问题。当它填满时，它会填满 - 但它不会使用户数据库（或整个服务器，如果 C 驱动器已满）脱机。
问：（DBCC SHRINKFILE）在 2008 年似乎不经常工作
它更多是 SQL Server 如何在每个版本中越来越依赖 TempDB 的功能。当 TempDB 中的某些内容处于活动状态时，您无法移动其数据，并且每个新版本的 SQL Server 在 TempDB 中都可以更有效地工作。例如，当您启用 Read Committed Snapshot Isolation 时，它使用的版本存储位于 TempDB 中。当您使用 AlwaysOn 可用性组时，它也会跟踪 TempDB 中的用户数据库统计信息。这只是您为 TempDB 留出一个逻辑卷，调整数据文件的大小以将其填满，然后走开的另一个原因 - 您的工作已经完成，不要尝试缩小这些文件。