TempDB mdf 文件的問題不斷增加
我有一個 tempdb 增長問題。讓我先給出我的 tempdb 設置。
即使沒有在數據庫/伺服器上執行任何查詢，tempdb 的大小也會不斷增加，起初是快速的，然後是緩慢的，沒有停止。我已經執行了許多查詢來確定正在執行的內容，下面是下面查詢的結果，它實際上給了我可以使用的結果。
可以看出它們都是內部 spid 有沒有辦法找出 tempdb 繼續失控的原因以及如何緩解它？對此問題的任何幫助將不勝感激。
--Query that returned the result set SELECT session_id, SUM(internal_objects_alloc_page_count) AS task_internal_objects_alloc_page_count, SUM(internal_objects_dealloc_page_count) AS task_internal_objects_dealloc_page_count FROM sys.dm_db_task_space_usage GROUP BY session_id HAVING SUM(internal_objects_alloc_page_count) > 0
那麼首先，為什麼您的數據文件增長設置為 1MB？如果您需要在 tempdb 中容納 20MB 的數據，該文件將不得不單獨增長 20 倍！想像一下，如果您有一個查詢需要 200MB 或 2GB 溢出到磁碟？哎呀。
增長事件代價高昂，尤其是在較舊的 SAS/SATA 儲存上，尤其是在您沒有啟用即時文件初始化的情況下。您真的應該嘗試預先調整文件大小，以便它們足夠大以容納您最繁忙的工作量，並完全避免增長事件。這並不總是可行的，但取而代之的是，增長規模應該更大。你真的希望這是一個罕見且孤立的事件，而不是不斷發生的事件。當它最終會使用更多空間時，保持 tempdb 小有什麼意義？您是否要將空間暫時出租給出價最高的人，然後驅逐他們？
另外，為什麼只有一個 tempdb 文件？這是一個常見的爭論來源。典型的智慧建議從 4 個文件開始，即使它們都在同一個磁碟上。這可以大大減少爭用，尤其是當多個並發程序試圖創建對像或以其他方式使用 tempdb 中的空間時。您可能還想查看啟用跟踪標誌 1117（確保所有數據文件同時增長）和跟踪標誌 1118（更改擴展區分配）。關於這些的連結如下。
當然，這些都不能解決您的核心問題 - 磁碟空間不足（或擔心）。如果您沒有足夠的磁碟空間來支持系統的目前使用情況（無論是系統還是您的使用者），請獲取更多磁碟空間，或移動系統。您可能能夠找到一些罪魁禍首（有關一些常見問題的答案，請參見此答案），但您無法將它們全部消滅。
您可能還會發現這些東西很有用：
- Jason Hall 的這篇博文
- 保羅蘭德爾的這項調查
- 這篇關於優化 tempdb 的 TechNet 文章
- 這個來自保羅蘭德爾的被壓扁的神話
- 這個關於 TF1118 的討論
- Paul White 的這篇博文，解釋了臨時對象記憶體
- 這個關於確定版本儲存使用的問題
- 這個答案（也連結在上面）關於確定 tempdb 日誌使用的貢獻者，以及首先使用 tempdb 的常見原因
- 上述答案的右側欄中還有三個“連結問題”可能有用
- 本文件關於 tempdb 大小的貢獻者
- 這個問題，也是關於 tempdb 大小的貢獻者
- mssqltips.com 上有關 tempdb 配置最佳實踐的提示
而且，既然我們知道您正在使用 Service Broker，您可能需要閱讀這兩個頁面，這可能有助於解釋為什麼您的對話沒有清除：
根據您列出的設置，我認為您的 tempdb 設置得非常小。對於一個小實例，嘗試從
1000MB數據文件和500MB日誌文件開始。然後將您的自動增長更改100MB為數據和50MB日誌。然後監控。如果您仍然獲得頻繁的增長，那麼嘗試將您的初始大小增加 X10 並將您的增長增加 x2 並再次監控。Tempdb 通常不會隨機增長。有東西在使用它。現在，如果這是您的個人電腦，那麼也許可以分別嘗試
100MB和 ，50MB但即便如此，當您實際做事時，我仍希望有一定程度的增長。當然，所有這些都取決於您有多少空間用於 tempdb。我的幾台生產伺服器都有 tempdbs，
100GB而且我看到的要大得多。