3

我的新组织中有一个 60 GB 的生产数据库。我们在一夜之间从这个数据库中运行了 500 份报告。我注意到所有报告脚本都在其中创建表格TempDB，然后填充最终报告。TempDB大小为 6 GB。没有为这些从 PowerShell 调用的报告脚本设置依赖项。

TempDB以这种方式广泛使用是一种好习惯吗？还是在生产数据库本身中创建所有暂存表并在生成报告后删除它们更好？

谢谢， 鲁佩什

4

1 回答 1

2

临时表总是在 TempDb 中创建。但是，TempDb 的大小不必仅取决于临时表。TempDb 以多种方式使用

  • 内部对象（排序和假脱机、CTE、索引重建、哈希连接等）
  • 用户对象（临时表、表变量）
  • 版本存储（AFTER/INSTEAD OF 触发器，MARS）

因此，很明显它正在用于各种 SQL 操作，因此大小也会由于其他原因而增长。但是，在您的情况下，如果您的 TempDb 有足够的空间来正常运行，并且您的内部进程正在使用 TempDb 创建临时表，这不是问题。您可以将 TempDb 视为 SQL Server 的厕所。

您可以使用以下查询检查导致 TempDb 大小增加的原因

SELECT
 SUM (user_object_reserved_page_count)*8 as usr_obj_kb,
 SUM (internal_object_reserved_page_count)*8 as internal_obj_kb,
 SUM (version_store_reserved_page_count)*8  as version_store_kb,
 SUM (unallocated_extent_page_count)*8 as freespace_kb,
 SUM (mixed_extent_page_count)*8 as mixedextent_kb
FROM sys.dm_db_file_space_usage

如果上面的查询显示，

  • 更多的用户对象意味着有更多的使用临时表，游标或临时变量
  • 更多的内部对象表明查询计划正在使用大量的数据库。例如：排序、分组等。
  • 更高数量的版本存储显示长时间运行的事务或高事务吞吐量

您可以通过上述脚本监控 TempDb 并首先确定其增长的真正原因。但是，60 GB 是一个相当小的数据库，6 GB 的 TempDB 大小是可以接受的。

上述答案的一部分是从我的其他答案中复制的。

于 2015-12-23T14:35:41.080 回答