SQL Server log_reuse_wait_desc 是 ACTIVE_TRANSACTION 但沒有活動事務

剛剛遇到了 SQL Server 2016 數據庫的問題，其中該查詢為 log_reuse_wait_desc 返回了 ACTIVE_TRANSACTION：

select name,log_reuse_wait_desc from sys.databases where name='database name'

1. 數據庫的恢復模式很簡單。
2. sys.dm_tran_database_transactions 報告沒有活動事務（對於任何數據庫）。
3. 數據庫（來自 sys.dm_db_log_stats）的活動日誌使用量約為 800MB。
4. 在相關期間未執行任何備份。

這種狀態持續了 18 小時，直到執行：

DBCC SHRINKFILE (N'database log file' , 0, TRUNCATEONLY)

這清除了 ACTIVE_TRANSACTION 狀態，並且活動日誌使用量下降到幾分之一 MB。

在清除日誌之前是否需要使用一些最低限度的日誌？我在許多其他具有相同配置的伺服器上沒有看到這個問題……

在數據庫檢查點將所有臟頁寫入數據文件之前，無法重用日誌，並且自動檢查點不會按固定時間表發生：

自動檢查點之間的時間間隔可能變化很大。與主要用於只讀操作的數據庫相比，具有大量事務工作負載的數據庫將具有更頻繁的檢查點。在簡單恢復模式下，如果日誌已滿 70%，自動檢查點也會排隊。

數據庫檢查點 - 自動檢查點

Hannah Vernon 在這裡更詳細地解釋了這種行為：

當日誌達到 70% 滿時，將發出一個檢查點。一旦發出此檢查點，即使日誌已滿 70% 以上，也可能不會發出進一步的檢查點，即使自動檢查點沒有導致日誌截斷活動。但是，如果生成了更多事務，並且數據庫引擎認為恢復時間會長於配置的恢復間隔，則只要正在生成事務，SQL Server 就會頻繁發出自動檢查點。如果沒有生成交易，則不會發出自動檢查點。

CHECKPOINT 和簡單恢復模型

所以你的

DBCC SHRINKFILE (N'database log file' , 0, TRUNCATEONLY)

直接或間接造成了一個檢查點。

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