0

虽然我从这篇文章中获得了一些进一步的见解，但我仍在努力更全面地了解我最近对变量表的使用以及相关的 tempdb 增长。

我最近一直在存储过程和表值函数中使用变量表。我对变量表 v 的本地/全局临时表的使用是可能影响我正在经历的更大挑战的一个领域。

由于使用这种类型的临时表，tempdb 已经增长到大约 50+GB 区域，并且在使用exec sp_spaceused @updateusage=true我正在查看的检查表时：database_size: 51935.13MB unallocated_space: 51908.80MB并且在检查数据库的内容时，不存在临时表或系统表。对于 ref tempdb.ldf 非常小。

在使用检查我的会话使用情况时，exec sp_who我还看到多行指示睡眠，我怀疑这可能是我们遇到连接未正确关闭的问题。

从阅读各种帖子和 SO 来看，普遍的共识是不要尝试缩小 tempdb 和相关文件，事实上，我更愿意解决根本问题，而不是转向更碎片化的数据存储。

关于为什么我现有的方法可能会影响 tempdb 增长以及使用本地/全局临时表是否更合适，是否有任何建议。

关于 tempdb 它是自身的，虽然存储很便宜，但我需要确保包含这种增长，因此任何有关维护的建议（将数据库拆分为多个文件、可能的缩小、将数据库移动到单独的驱动器）等都将不胜感激。

4

1 回答 1

0

您可以检查 tempdb 数据库中的对象以了解发生了什么

以下代码列出了 tempdb 中的对象，并根据创建日期和计算持续时间（以分钟为单位）进行 asc 排序

use TempDb
go

SELECT 
 name ,object_id , SCHEMA_NAME(schema_id) obj_schema,
 type ,  type_desc,
 create_date ,  modify_date, 
 OBJECT_NAME(parent_object_id)  parent_obj ,
 DATEDIFF(hour,create_date , GETDATE()) duration_hour
FROM sys.objects  
where name  not like 'sys%'
order by create_date

tempDb 中的对象分为三组：

  • 内部对象
  • 外部对象
  • 版本存储

以下代码显示了为每个类别分配了多少 tempdb 磁盘空间

SELECT 
SUM(user_object_reserved_page_count)/128.0 UserObjectsMB,
SUM(user_object_reserved_page_count) UserObjectPages_count  ,

SUM(version_store_reserved_page_count)/128.0 VersionStoreMB,
SUM(version_store_reserved_page_count) VersionStorePages_count, 

SUM(internal_object_reserved_page_count) InternalObjectPages_count, 
SUM(internal_object_reserved_page_count)/128.0 InternalObjectsMB,

SUM(unallocated_extent_page_count)/128.0 FreeSpaceMB,
SUM(unallocated_extent_page_count)  FreePages_count

FROM sys.dm_db_file_space_usage;

您可以查看： local-and-global-temporary-tables-in-sql-server

tempdb 的大小应该足以应付日常和高峰工作负载，以避免在 WorkLoad 运行时增长。

我的建议，除非有必要，否则不要在启动期间或任何其他时间缩小 tempDb。存储很便宜，您可以为 tempDb（甚至 SSD）分配专用存储

更多细节：

tempdb 的容量规划

优化 tempdb 性能

于 2016-07-27T15:05:48.503 回答