查找 tempdb 膨脹的 SQL 查詢

我試圖找出會執行並導致 TempDB 膨脹的查詢。

我能夠在某一天提取像 TempDB 膨脹這樣的數據，它幾乎佔用了 300 GB 的空間，是在上周中旬的某個地方。

根據文章如何找到導致 tempdb 增長的 SQL 語句？，我可以找到以下數據，但不確定如何解釋，因為我可以找到主機和登錄名，但不是實際的查詢。

status  CPU TIME (in milisec)   Total Scheduled TIME (in milisec)   Elapsed TIME (in milisec)   Memory USAGE (in KB)    SPACE Allocated FOR USER Objects (in KB)    SPACE Deallocated FOR USER Objects (in KB)  SPACE Allocated FOR Internal Objects (in KB)    SPACE Deallocated FOR Internal Objects (in KB)  SESSION Type    ROW COUNT
sleeping    4428523 4618020 5418422 24  0   648 38349248    38351104    user session    1
sleeping    4411334 4578428 5389351 24  0   672 41238720    41240448    user session    1
sleeping    4601627 4820643 5631623 24  0   720 40119104    40121280    user session    1
sleeping    12887505    13667397    15209924    24  0   3528    46007808    46013184    user session    1
sleeping    4589595 4792873 5835456 24  0   528 39140800    39142528    user session    1
sleeping    6416738 6767615 7836356 24  0   1088    40406400    40408768    user session    1
sleeping    8626603 9072173 10416679    24  0   1488    43888640    43891584    user session    1
sleeping    4346345 4554241 5389904 24  0   976 39358208    39360128    user session    1
sleeping    11817344    12427608    13494857    24  0   3208    46888512    46894208    user session    1
sleeping    5182063 5435636 6242939 24  0   680 37975040    37977024    user session    1

有沒有辦法讓我真正找到上週導致近 300 GB 膨脹的查詢。

是的，我知道可以保存資訊的 3rd 方工具。但是我們沒有這方面的內容。如果可能的話，我怎樣才能找到一個？

預設情況下，SQL Server 不會跟踪和記錄導致 TempDB 增長的查詢。此外，在這種情況下，即使執行 SQL Profiler 會話也無濟於事。

但是，擴展事件是一種選擇。Brent Ozar 有一篇部落格文章，其中包含一個範例：

使用擴展事件跟踪 tempdb 增長

XE 會話比 SQL Profiler 跟踪更輕量級。此外，預設情況下，您的伺服器現在可能已經執行了兩三個。

XE 會話可以設置為以環形緩衝區為目標，因此它們可以完全位於記憶體中並擷取超過某個門檻值（例如 20 GB 或更多）的查詢。在這種情況下，它們引起任何問題的風險很小。

引用自：https://dba.stackexchange.com/questions/202325