TempDB用法SQL Server 2012

Question

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

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

谢谢， Roopesh

Answer 1

临时表总是在TempDb中创建。但是，TempDb的大小不一定仅仅是临时表。 TempDb以各种方式使用

• 内部对象（Sort＆amp; spool，CTE，index rebuild，hash join等）
• 用户对象（临时表，表变量）
• 版本存储（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

如果上面的查询显示，

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

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

以上部分答案是从我的other answer复制而来的。