TempDB 日誌文件增長之謎的緊急幫助

對於過去上週的 tempdb 問題，我需要一些緊急指導：

tempDB 日誌文件從特定時間開始增長，比如說下午 2 點。並且幾乎繼續增長到 150 GB，然後在 10 個小時左右後下降。

我使用了此處列出的各種查詢，但沒有顯示任何內容，因為在此期間沒有長時間執行的事務。

混合工作負載的查詢不斷湧現。沒有這樣的卡住交易。

此實例上的使用者數據庫都是日誌傳送設置的一部分，日誌備份每 15 分鐘發生一次。

另外我添加了 Xevent

CREATE EVENT SESSION [tempdb_file_size_changed] ON SERVER ADD EVENT 
sqlserver.database_file_size_change(SET collect_database_name=(1)ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.is_system,sqlserver.query_hash,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username) WHERE ([database_id]=(2))) ADD TARGETpackage0.event_file(SET filename=N'C:\ExtendedEvents\TempDBGrowth.xel',max_file_size=(100),max_rollover_files=(25)) WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)

即使在 XE 中也沒有任何內容被擷取，並且在那 10 個小時內它只是空白。

我不知道是什麼在吃我的 tempDB 日誌，因為沒有任何查詢或 XE 獲取我的數據。我從來沒有見過這個東西，通常使用 XE 來獲得數據庫增長，但在這裡我一無所知。

我正在跑步DBCC SQLPERF(logspace)，我可以看到使用的日誌每 5 分鐘左右不斷增加 1 Gb。我們將 TempDB 日誌設置為最大 200 GB，但到了 10 小時，它幾乎達到 160-180 GB，然後突然下降。

幾乎每次在查詢下方執行都會給出 ACTIVE TRANSACTION。

SELECT log_reuse_wait, log_reuse_wait_desc 
FROM sys.databases d 
WHERE database_id = 2;

請幫助我可能做錯了什麼以及為什麼我看不到任何使用 TempDB 日誌文件使用的事務？

更新 - 按照@JD 的回答要求，我檢查並確認沒有數據庫郵件或服務代理在內部被用於導致增長：

然而在上週我看到 tempdb 的日誌文件的增長是曲折的，曲折增長的趨勢有點高：

我需要幫助理解：-

事務日誌的增長是如何增長到 80%，然後再下降到 0，然後再增長和增長等等，達到 lmoast max 90-95%。

我確認沒有手動收縮。可能有多個程序參與，因為這是全天使用 tempdb 的 OLTP 伺服器。只是不明白上週它是如何增長到接近其最大容量的？

謝謝

您所看到的是 tempdb 事務日誌文件的設計。我希望微軟對此有更好的文件。

事務日誌增長是如何增長到 80%，然後再降到 0，然後再增長和增長等等，幾乎達到最大 90-95%。

從第一篇參考文章：

Tempdb 在發生崩潰時不會恢復，因此無需將臟 tempdb 頁面強制寫入磁碟，除非lazywriter 程序（緩衝池的一部分）必須為其他數據庫的頁面騰出空間。

僅當 tempdb 日誌文件 **已滿 70%**時才會為 tempdb 執行檢查點——這是為了盡可能防止 tempdb 日誌增長（請注意，長時間執行的事務本質上仍然可以將日誌作為人質並阻止其清除，就像在使用者數據庫中一樣）。

當然，當您發出手動檢查點時，所有臟頁都會被刷新，但對於自動檢查點，它們不會。

我建議您監控您的 tempdb 事務日誌使用情況並將其設置為合理的大小，在正常工作負載下它不必增長和縮小。

我不知道為什麼你的 tempdb 日誌文件填充到 100%。日誌文件沒有被截斷一定是有原因的。

間接檢查點會有幫助嗎？

在大多數情況下沒有。

任何符合 tempdb 中“急切寫入”條件的未記錄“批量”操作都不會被恢復寫入器（執行間接檢查點的內部執行緒）刷新。

這就提出了一個重要的問題：在 tempdb 上最少記錄哪些數據載入操作？了解這一點很重要，因為間接檢查點不會刷新 tempdb 上的最小記錄操作。以下列表可用於幫助您了解 tempdb 上的哪些載入操作將被最少記錄，哪些不會。

有關詳細資訊，請閱讀Tempdb – 這是Fabiano Amorim 所不知道的問題

我注意到這個問題是針對SQL Server 2014，如果有人正在閱讀此SQL Server 2016文件以閱讀 Microsoft 的以下文件。

1. 數據庫檢查點 (SQL Server) - 檢查“間接檢查點”部分。
2. 更改數據庫 (SQL Server) 的目標恢復時間。
3. 間接檢查點和 tempdb—— Parikshit Savjani的好、壞和不產生影響的調度程序

參考：

1. 檢查點對 tempdb 有什麼作用？保羅·蘭德爾
2. 請參閱問答部分儲存引擎內部：緩衝池中有什麼？保羅·蘭德爾

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