使用變量表，tempdb增長和數據庫會話睡眠

Question

雖然我從this post得到了一些進一步的見解，但我仍在努力更全面地理解我最近使用的變量表和相關的tempdb增長。

我最近在存儲過程和表值函數中都使用了變量表。我使用變量表v的本地/全局臨時表是一個可能影響我遇到的更大挑戰的領域。

由於使用這種類型的臨時表的tempdb的已發展到周圍的50 + GB區域，並使用exec sp_spaceused @updateusage=true檢查表時我看到：database_size: 51935.13MBunallocated_space: 51908.80MB和檢查DB的內容時沒有臨時或系統表是本。對於ref而言，tempdb.ldf非常小。

在使用exec sp_who檢查我的會話使用情況時，我也看到多個表示睡眠的行，我懷疑這可能是我們遇到連接不正常關閉的問題。

從閱讀各種職位和SO的普遍共識是不試圖縮小tempdb和相關文件，事實上我寧願解決根本問題，而不是移動到更零散的數據存儲。

有沒有關於爲什麼我現有的方法可能會影響tempdb增長以及是否使用本地/全局臨時表更合適的建議。

關於tempdb它是自己的，而存儲是便宜的，我需要確保這個增長包含所以任何關於維護的建議（將數據庫拆分成多個文件，可能收縮，將數據庫移動到一個單獨的驅動器）等讚賞。

Answer 1

您可以檢查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）

分配專用存儲更多的細節：

Capacity Planning for tempdb

Optimizing tempdb Performance