TempDB性能爬行;我們應該重啓嗎？

Question

有點背景：我們在服務器上有17個不同的TempDB數據庫文件和6個TempDB日誌文件。這些分佈在不同的驅動器上，但託管在2個驅動器陣列上。

我看到磁盤IO響應時間超過建議的限制。通常你希望你的磁盤在5-10ms內響應，沒有超過200ms。我們在TempDB文件中看到高達800ms的隨機尖峯，但只能在一個驅動器陣列上看到。

建議的解決方案：重新啓動SQL服務器。在關閉SQL服務器的同時，重新啓動託管大部分TempDB文件的驅動器陣列。另外，當SQL關閉時，重做網絡連接以繞過網絡交換機，試圖消除硬件緩慢的任何來源。

這是一個好主意還是在黑暗中拍攝？有任何想法嗎？ 在此先感謝。

Answer 1

17？誰提出了這個數字？ Please read this和this - 極少數情況下，> 8個文件將有所幫助，特別是如果您只有2個底層陣列/控制器。一些建議：

1. 使用偶數個文件。大多數人從4或8開始，只有當他們證明他們仍然存在爭用（並且也知道他們的底層I/O實際上可以處理更多文件並與它們一起擴展時纔會增加）;在某些情況下，它將不會效果或完全相反的效果 - 不同的驅動器號不一定意味着更好的I/O路徑）。
2. 確保所有數據文件的大小相同，並具有相同的自動增長設置。擁有17個不同大小和自動增長設置的文件將挫敗輪循機制 - 在很多情況下，由於SQL Server執行比例填充的方式，只會使用一個文件。奇數似乎......好吧，對我來說很奇怪。
3. 擺脫5個額外的日誌文件。 They are absolutely useless。
4. 使用跟蹤標誌1117來確保所有數據文件在相同的時間和（因爲2.）以相同的速率增長。請注意，此跟蹤標誌適用於所有數據庫，而不僅僅是tempdb。 More info here。
5. 您也可以考慮跟蹤標誌1118來更改分配，但請read this first。
6. 確保instant file initialization處於打開狀態，以便文件擴展時不必將其清零。
7. 預先設置tempdb文件的大小，以便在正常的日常活動中不需要增長。不要收縮tempdb文件，因爲它們突然變大了 - 這只是一次沖洗和重複操作，因爲如果它們有一次這麼大，它們會再次變大。這不像你可以在此期間租出恢復的空間。
8. 如果可能，請在其他地方執行DBCC CHECKDB。如果你經常運行CHECKDB，耶！輕拍自己的背部。但是，這可能會對tempdb - please see this article on optimizing this operation造成影響，並在可行的情況下將其從生產實例中拉出。
9. 最後，驗證您看到的是什麼類型的爭用。你說tempdb性能爬行，但以什麼方式？你如何衡量這個？ Some info on determining the exact nature of tempdb bottlenecks here和here和here和here和here。

您是否考慮過少使用tempdb（更少的#temp表，@table變量和靜態遊標 - 或者遊標）？您是否大量使用RCSI或MARS或LOB類型的局部變量？