标签: tempdb

我有一种情况，我对 TempDB 的大小有限制，不能超过 350 GB。我autogrowth 10在 TempDB 上使用（百分比），因为我读到它应该是超过 500 MB 的数据库的最佳实践。

当我使用

 dbcc checkdb with estimateonly 

在每个数据库上，我注意到 TempDB 的估计需求比我目前的需求低得多。将 返回的值相加dbcc checkdb with estimateonly得到大约 75 GB 的值。

TempDB 的大小目前为 300 GB。我无法进一步增加 TempDB 的允许大小。

我听说我们公司以前有一个 SQL 作业，如果它超过某个值，它会自动缩小 TempDB，但它没有在我们的新环境中使用。然而，我很矛盾，对缩小 TempDB 过于宽松可能会导致问题。

使用这篇文章中的信息，如果当前大小超过 200 GB 左右，将 TempDB 自动收缩到 200 GB 大小是否存在任何重大风险，看到dbcc checkdb with estimateonly返回的估计最小大小为 75 GB，这将导致这一个相当高的相对缓冲？

我读过这不是缩小 TempDB 的最佳做法，但在这种情况下，参考 TempDB 的估计最小大小，它可能更“合法”吗？

编辑

我做了以下查询，例如，internal object MB space, internal object dealloc MB space, statement text（查询）, total …

下面我有一个代码来获取有关服务器中每个数据库的 t-log 备份的信息。我想从这个列表中排除 tempdb。

exec sp_MSforeachdb 'SELECT server_name, sysdb.name AS DatabaseName, bkup.user_name AS [User],
ceiling(bkup.backup_size /1048576) as ''Size Meg'' ,
cast((bkup.backup_size /1073741824) as decimal (9,2)) as ''Gig'',
bkup.backup_start_date AS [Backup Started],
bkup.backup_finish_date AS [Backup Finished (Last BackUp Time)],
CAST((CAST(DATEDIFF(s, bkup.backup_start_date, bkup.backup_finish_date) AS int))/3600 AS varchar) + '' hours, ''
+ CAST(DATEDIFF(mi, bkup.backup_start_date, bkup.backup_finish_date) - (DATEDIFF(mi, bkup.backup_start_date, bkup.backup_finish_date)/60)*60 AS varchar) + '' minutes, ''
+ CAST((CAST(DATEDIFF(s, bkup.backup_start_date, bkup.backup_finish_date) AS int))%60 AS varchar)+ '' seconds'' AS [Total Time]
,DATEDIFF(DAY,CONVERT(CHAR(8),backup_finish_date,112),CONVERT(CHAR(8),expiration_date,112)) AS expiration_days
,bms.description …

我一直在挠头，重新阅读MSFT帮助，但我仍然无法理解sys.dm_db_index_operational_stats和sys.dm_db_index_physical_stats中的forwarded_fetch_count和forwarded_record_count之间的区别。让我用下面的例子来说明我理解观点的问题。

我运行了以下查询：

;with heaps as ( \nselect \n    DB_NAME(DB_ID()) dbname, object_name ( p.object_id ) objname, sum(row_count) row_count,\n    DB_ID() database_id, p.object_id objectid\nfrom \n    sys.dm_db_partition_stats p\n    join sys.objects o on o.object_id = p.object_id \nWHERE \n    index_id = 0 and o.is_ms_shipped = 0 --and row_count > 0\n    group by p.object_id ) \nselect \n    h.*, \n    forwarded_fetch_count\nfrom heaps h\n    cross apply sys.dm_db_index_operational_stats(database_id, objectid, 0, null) ps\n    WHERE forwarded_fetch_count > 0 ORDER BY forwarded_fetch_count DESC\xc2\xa8\n

和

SELECT …

给定 2 个 SQL Server 实例，其中第二个实例配置有用于 tempdb 的 RAMDisk 和以下测试用例。

-- Create source data
select top(1000000) * /* ~10 cols */ into #t1 from SomeData;

然后测量这些级联选择的总运行时间；

-- Benchmark  
select * into #t4 from #t1;
select * into #t5 from #t4;
select * into #t6 from #t5;

我的运行时间是一样的~（15s vs ~15s）。一个 CPU 在整个测试期间都达到最大值。

有没有办法加快跨 CPU 的查询（是 tempdb 文件分区）吗？

通过评论请求数据：

The 1 CPU is the SQL Server 2012 process on a 12 CPU server circa 2012.
Machine: 24GMb RAM, HardDrives: 10kRpm x 2 …