SQL Server中造成日志截斷延遲可能的原因

主要通過sys.database表中 log_reuse_wait 和 log_reuse_wait_desc 列來檢視具體的造成延遲的原因

log_reuse_wait列的具體含義：

log_reuse_wait 值 log_reuse_wait_desc 值 描述

• 0：NOTHING 目前有一個或多個可重複使用的虛拟日志檔案 (VLF)。

• 1：CHECKPOINT 自上次日志截斷之後，尚未生成檢查點，或者日志頭尚未跨一個虛拟日志 (VLF) 檔案移動。 （所有恢複模式）

  這是日志截斷延遲的常見原因。 有關詳細資訊，請參閱資料庫檢查點 (SQL Server)。

• 2：LOG_BACKUP 在截斷事務日志前，需要進行日志備份。 （僅限完整恢複模式或大容量日志恢複模式）

  完成下一個日志備份後，一些日志空間可能變為可重複使用。

• 3：ACTIVE_BACKUP_OR_RESTORE 資料備份或還原正在進行（所有恢複模式）。

  如果資料備份阻止了日志截斷，則取消備份操作可能有助于解決備份直接導緻的此問題。

• 4：ACTIVE_TRANSACTION 事務處于活動狀态（所有恢複模式）：

  一個長時間運作的事務可能存在于日志備份的開頭。 在這種情況下，可能需要進行另一個日志備份才能釋放空間。 請注意，長時間運作的事務将阻止所有恢複模式下的日志截斷，包括簡單恢複模式，在該模式下事務日志一般在每個自動檢查點截斷。

  延遲事務。 “延遲的事務 ”是有效的活動事務，因為某些資源不可用，其復原受阻。 有關導緻事務延遲的原因以及如何使它們擺脫延遲狀态的資訊，請參閱延遲的事務 (SQL Server)。

  長時間運作的事務也可能會填滿 tempdb 的事務日志。 Tempdb 由使用者事務隐式用于内部對象，例如用于排序的工作表、用于哈希的工作檔案、遊标工作表，以及行版本控制。 即使使用者事務隻包括讀取資料（SELECT 查詢），也可能會以使用者事務的名義建立和使用内部對象， 然後就會填充 tempdb 事務日志。

• 5：DATABASE_MIRRORING 資料庫鏡像暫停，或者在高性能模式下，鏡像資料庫明顯滞後于主體資料庫。 （僅限完整恢複模式）

  有關詳細資訊，請參閱資料庫鏡像 (SQL Server)。

• 6：REPLICATION 在事務複制過程中，與釋出相關的事務仍未傳遞到分發資料庫。 （僅限完整恢複模式）

  有關事務複制的資訊，請參閱 SQL Server Replication。

• 7：DATABASE_SNAPSHOT_CREATION 正在建立資料庫快照。 （所有恢複模式）

  這是日志截斷延遲的常見原因，通常也是主要原因。

• 8：LOG_SCAN 發生日志掃描。 （所有恢複模式）

  這是日志截斷延遲的常見原因，通常也是主要原因。

• 9：AVAILABILITY_REPLICA 可用性組的輔助副本正将此資料庫的事務日志記錄應用到相應的輔助資料庫。 （完整恢複模式）

  有關詳細資訊，請參閱： AlwaysOn 可用性組概述 (SQL Server)。

• 10： - 僅供内部使用
• 11： - 僅供内部使用
• 12： - 僅供内部使用

• 13： OLDEST_PAGE 如果将資料庫配置為使用間接檢查點，資料庫中最早的頁可能比檢查點日志序列号 (LSN) 早。 在這種情況下，最早的頁可以延遲日志截斷。 （所有恢複模式）

  有關間接檢查點的資訊，請參閱資料庫檢查點 (SQL Server)。

• 14：OTHER_TRANSIENT 目前未使用此值。