2

我们有一个 SQL Server 2000 生产环境，其中突然（即最近 3 天）某些事情导致 tempdb 数据文件变得非常大（45 gigs，而数据库只有 10 gigs）。昨天，再次发生后，我们缩小了数据库并单独运行了主要的批处理过程，没有任何问题。然而，今天早上数据库恢复到 45 个演出。

有没有一种简单的方法可以找出导致这个数据库变得如此之大的原因？理想情况下，今天可以查看的内容，但如果不可用，则可以设置为明天获取该信息。

顺便说一句：缩小数据库会在几秒钟内收回空间。

4

5 回答 5

2

同意 Jimmy 的观点，您需要使用 SQL Profiler 来查找创建如此密集的临时对象。这可能是使用某些报告或类似内容的临时表。

于 2009-07-13T15:02:04.613 回答
1

我要感谢大家的回答，因为他们肯定导致了问题的原因。

我们打开了 SQL 分析器，果然出现了很大的批量负载。由于我们正在开展一个项目以将“有问题的”工作转移到 mysql 中，我们现在可能只是看事情。

于 2009-07-15T01:59:01.403 回答
0

您是否正在运行重建索引的作业？它可能使用 SORT_IN_TEMPDB

或任何其他进行排序的大型查询可能会扩展 tempdb

于 2009-07-13T15:05:05.593 回答
0

这可能与 TempDB 设置的恢复模式有关。它可以设置为 FULL 而不是 BULK-LOGGED。完全恢复会增加事务日志的大小，直到执行备份。

查看数据文件大小与事务日志大小。

于 2009-07-13T15:05:06.670 回答
0

我不是DBA，但有一些想法：

  • 是否有可能创建了临时表但没有删除？ ##tempTable?
  • 是否有可能正在创建（并删除）一个大型临时表但没有回收空间？
  • 您是否在系统可能使用临时表的地方进行任何类型的批量加载？（我不确定您是否可以）但是您可以为 tempdb 打开 Auto-Shrink 吗？
于 2009-07-13T15:41:14.570 回答