2016-07-27 55 views
0

雖然我從this post得到了一些進一步的見解,但我仍在努力更全面地理解我最近使用的變量表和相關的tempdb增長。使用變量表,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它是自己的,而存儲是便宜的,我需要確保這個增長包含所以任何關於維護的建議(將數據庫拆分成多個文件,可能收縮,將數據庫移動到一個單獨的驅動器)等讚賞。

+0

在SQL Server 7天24小時工作日內,也可以是下 ? –

+0

你試圖解決什麼是「潛在問題」?在過去的某個時候,你的使用需要TempDB增長到今天的大小。如果它不能繼續增長,那就需要它的大小,直到出現需要更多空間的事情。 – alroc

回答

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)

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

Capacity Planning for tempdb

Optimizing tempdb Performance