我們如何限制 SQL Server 上特定使用者或查詢的 tempdb 使用？
在我們的 SQL Server 生產環境中，一些使用者執行臨時查詢，這些查詢將大量數據提取到 tempdb 中並將其填滿，從而導致生產伺服器出現問題。由於這些報告/查詢從前端執行，它們有時會混淆將數百萬行拉到臨時表的日期範圍。是的，使用者需要接受教育，也需要調整，我們已經這樣做了，但他們仍然偶爾會產生問題。
現在他們說在 SAP ASE (Sybase) 中有一個功能可以創建多個 tempdb 並重定向使用者並限制使用，而不會使單個 tempdb 膨脹（就像在 SQL Server 中一樣）並關閉伺服器。
我們在 SQL Server 中有這樣的東西嗎？
正如您所提到的，使用者需要接受教育，並且查詢需要重寫以更有效地使用更少的 tempdb。
SQL Server 沒有多個 tempdb 的概念，也不能通過使用者可以從 tempdb 使用多少空間來限制使用者。
一種解決方案會起作用，但它不是最好的。監控每個會話的 tempdb 使用情況並根據數量做出決定。您可以決定終止會話，但您需要考慮業務影響嗎？您是否建議它們稍後在伺服器活動較少時重新執行？在影響業務底線之前，企業可以等待多長時間才能重新執行？
在對 SQL Server 中的某些角色組實施執行時間/TempDB 使用限制的可能性中的一些建議？如果您決定選擇此路線，請參閱此問答。
正如已經建議的那樣，不可能以您想要的方式限制 TempDB 的使用，除了執行時間限制和簡單地完全阻止它。
如果可以分離可能產生這種模式的查詢類型，或者因為您控制應用程序並且可以在這方面給它一些智能，或者人們正在使用其他工具更直接地登錄到數據庫，那麼您可以執行針對副本/鏡像/其他而不是主數據庫的可能令人討厭的報告。這至少會阻止影響主應用程序的有問題的查詢。
沒有什麼可以阻止此報告實例位於同一伺服器上，但它至少希望位於其自己的 SQL Server 實例中，因此它不會與主應用程序 DB 共享 TempDB。“額外”的 TempDB 可以有自己的增長限制，並且可能位於不同的驅動器上（或者，如果使用 SAN 儲存安排，則可以在不同的 IOP 池上），您也可以人為地限制新實例的 CPU 和記憶體使用（給主應用程序優先級），如果它們共享資源。除了額外的管理員之外，這個想法的主要問題是它會產生許可影響，除非您的數據足夠小以適合快速版本的限制（如果它足夠大以至於這個問題經常成為問題，我認為這不太可能）你）因此可能不是一個實際的選擇。
即使在此報告實例上，您可能仍希望施加其他限制，以阻止真正令人討厭的查詢阻塞只是有點討厭的查詢，或者將副本拉低以至於需要努力使其稍後恢復同步。
作為其他建議的旁白：當阻止 TempDB 訪問以停止創建臨時表時，要小心編寫臨時 SQL 的“聰明”使用者，他們可能會做比現在更糟糕的事情來解決這個限制！