我们的新组织中有一个60 GB的生产数据库。我们在这个数据库中隔了近500个报告。我注意到所有报告脚本都在TempDB
中创建表格,然后填充最终报告。 TempDB
大小是6 GB。这些报告脚本没有设置依赖项,这些脚本是从PowerShell调用的。TempDB用法SQL Server 2012
以这种方式广泛使用TempDB
是否是一种好习惯?或者,在生产数据库本身中创建所有临时表并在生成报告后放下它们会更好吗?
感谢, Roopesh
我们的新组织中有一个60 GB的生产数据库。我们在这个数据库中隔了近500个报告。我注意到所有报告脚本都在TempDB
中创建表格,然后填充最终报告。 TempDB
大小是6 GB。这些报告脚本没有设置依赖项,这些脚本是从PowerShell调用的。TempDB用法SQL Server 2012
以这种方式广泛使用TempDB
是否是一种好习惯?或者,在生产数据库本身中创建所有临时表并在生成报告后放下它们会更好吗?
感谢, Roopesh
临时表总是被在tempdb中创建。但是,TempDb的大小不一定只是由于临时表。 tempdb的用于以各种方式
因此,很显然它在各种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中复制而来。
使用tempdb没有错(明确地)。通常tempdb是隐式使用的(即在你的控制之外)。 –