2015-12-17 62 views
3

我们的新组织中有一个60 GB的生产数据库。我们在这个数据库中隔了近500个报告。我注意到所有报告脚本都在TempDB中创建表格,然后填充最终报告。 TempDB大小是6 GB。这些报告脚本没有设置依赖项,这些脚本是从PowerShell调用的。TempDB用法SQL Server 2012

以这种方式广泛使用TempDB是否是一种好习惯?或者,在生产数据库本身中创建所有临时表并在生成报告后放下它们会更好吗?

感谢, Roopesh

+0

使用tempdb没有错(明确地)。通常tempdb是隐式使用的(即在你的控制之外)。 –

回答

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是相当小的数据库,6GB的TempDB大小是相当可接受的。

上述答案的一部分从我的other answer中复制而来。