事務歷史記錄檔 （SQL Server）

每個 SQL Server 資料庫都擁有交易記錄來記錄所有交易，以及交易在資料庫中所作的修改。 交易記錄檔必須定期截斷，以防止其填滿。 不過，某些因素可能會延遲記錄截斷，因此監視記錄大小很重要。 某些作業可使用最低限度記錄，以減少其對交易記錄大小的影響。

事務歷史記錄是資料庫的重要元件，如果系統失敗，可能需要事務歷史記錄，才能讓資料庫回到一致的狀態。 除非您完全了解執行這項作業的後果，否則絕不應刪除或移動事務歷史記錄。

備註

檢查點會在資料庫復原期間建立開始套用交易記錄的已知恰當起點。 如需詳細資訊，請參閱資料庫檢查點 (SQL Server)。

本主題內容：

優點：交易日志支援的作業

交易記錄檔支援下列作業：

  • 復原個別交易。

  • 在 SQL Server 啟動時復原所有未完成的交易。

  • 將還原的資料庫、檔案、檔案群組或頁面向前復原到失敗點。

  • 支援異動複寫。

  • 支援高可用性和災害復原解決方案：AlwaysOn 可用性群組、資料庫鏡像和記錄傳送。

交易日誌截斷

記錄截斷會釋出記錄檔中的空間，以供交易記錄重複使用。 記錄截斷是防止記錄填滿的重要措施。 記錄截斷會從 SQL Server 資料庫的邏輯事務歷史記錄中刪除非作用中的虛擬記錄檔，釋放邏輯記錄檔中的空間供實體事務歷史記錄重複使用。 如果交易日志從未被截斷，最終會佔滿所有分配給其物理日志檔案的磁碟空間。

若要避免此問題，除非因為某些原因而延遲記錄截斷，否則截斷會在下列事件之後自動發生：

  • 在簡單復原模式下，發生在檢查點之後。

  • 在完整恢復模式或大容量日誌恢復模式下，如果自上一次備份以來發生檢查點，則截斷會在記錄備份之後發生（除非它是僅限複製的記錄備份）。

如需詳細資訊，請參閱本主題稍後 可延遲記錄截斷的因素。

備註

記錄截斷不會減少實體記錄檔的大小。 若要減少實體記錄檔的實體大小，您必須壓縮記錄檔。 如需壓縮實體記錄檔大小的相關信息，請參閱 管理事務歷史記錄檔的大小。

可能會延遲記錄截斷的因素

當記錄檔記錄長時間保持作用中時，事務歷史記錄截斷會延遲，而且事務歷史記錄可能會填滿。

這很重要

如需如何回應完整事務歷史記錄的詳細資訊，請參閱針對完整事務歷史記錄進行疑難解答 （SQL Server 錯誤 9002）。

記錄截斷可能會因各種因素而延遲。 您可以藉由查詢 sys.databases 目錄檢視中的log_reuse_wait和log_reuse_wait_desc 列，來發現是否有任何因素阻止紀錄截斷。 下表描述這些資料行的值。

log_reuse_wait 值 log_reuse_wait_desc 值 說明
0 無 目前有一或多個可重複使用的虛擬記錄檔。
1 檢查站 自上次記錄截斷之後，沒有發生檢查點，或記錄的前端尚未移至虛擬記錄檔之外。 （所有恢復模式）

這是延遲記錄截斷的一般原因。 如需詳細資訊，請參閱資料庫檢查點 (SQL Server)。
2 日誌備份 在截斷交易記錄前，需要進行記錄備份。 (僅限完整或大量記錄復原模式)

當下一個記錄備份完成後，某些記錄空間可能就可以重複使用。
3 啟動備份或還原 數據備份或還原正在進行中（所有恢復模式）。

如果資料備份阻礙截斷記錄，則取消備份作業可能有助於化解眼前的問題。
4 ACTIVE_TRANSACTION 交易為作用中 （所有恢復模式）。

長時間執行的交易可能存在於記錄備份的開頭。 在此情況下，釋出空間可能需要另一個記錄備份。 請注意，長時間執行的交易會防止所有恢復模式下的記錄截斷，包括簡單的恢復模式，在每次自動檢查點上通常會截斷事務歷史記錄。

延遲交易。 「延遲交易」 實際上是回復遭到封鎖的使用中交易 (因為某些無法使用的資源所造成)。 如需延遲交易的原因以及如何使延遲交易脫離延遲狀態的相關資訊，請參閱延遲交易 (SQL Server)。

長時間執行的交易也可能填滿tempdb的事務歷史記錄。 Tempdb 會隱含地供內部物件使用，例如用於排序的工作數據表、哈希的工作檔案、數據指標工作數據表和數據列版本設定。 即使使用者交易只包含讀取數據（SELECT 查詢），內部物件仍可在使用者交易下建立及使用。 然後，tempdb 的交易日誌可能會被填滿。
5 資料庫鏡像 資料庫鏡像已暫停，或者在高效能模式下，鏡像資料庫已大幅落後主體資料庫。 (僅限完整復原模式)

如需詳細資訊，請參閱資料庫鏡像 (SQL Server)。
6 複製 進行異動複寫期間，與發行集相關的交易仍然未傳遞至散發資料庫。 (僅限完整復原模式)

如需有關異動複寫的詳細資訊，請參閱＜ SQL Server Replication＞。
7 資料庫快照建立 正在建立資料庫快照集。 （所有恢復模式）

這是延遲記錄截斷的一般原因 (通常也是暫時的原因)。
8 LOG_SCAN 正在進行記錄掃描。 （所有恢復模式）

這是延遲記錄截斷的一般原因 (通常也是暫時的原因)。
9 可用性副本 可用性群組的次要複本正在將這個資料庫的交易記錄檔記錄套用到對應的次要資料庫。 （完整恢復模式）

如需詳細資訊，請參閱 AlwaysOn 可用性群組概觀（SQL Server）。
10 - 僅供內部使用
11 - 僅供內部使用
12 - 僅供內部使用
13 最古老的頁面 如果資料庫設定為使用間接檢查點，資料庫上最舊的頁面可能會比檢查點 LSN 舊。 在此情況下，最舊的頁面可能會延遲日誌截斷。 （所有恢復模式）

如需間接檢查點的相關信息，請參閱 資料庫檢查點 （SQL Server） 。
14 OTHER_TRANSIENT 目前未使用此值。
16 XTP_CHECKPOINT 當資料庫具有記憶體優化檔案群組時，在自動觸發 In-Memory OLTP 檢查點之前，交易日誌可能不會截斷（這會在每 512 MB 的日誌增長時發生）。

注意：若要在 512 MB 大小之前截斷交易日誌，請針對相關的資料庫手動執行 Checkpoint 命令。

可最低限度記錄的作業

「最低限度記錄」 包含僅記錄復原交易所需的資訊，不支援時間點復原。 本主題識別在大容量記錄恢復模式下最低限度記錄的操作（以及在簡單恢復模式下，但備份執行時除外）。

備註

記憶體優化數據表不支援最低限度記錄。

備註

在完整恢復模式下，會完全記錄所有批量操作。 不過，您可以暫時針對大量作業，將資料庫切換成大量記錄復原模式，藉以將大量作業集的記錄降至最低。 最低限度記錄會比完整記錄更具效率，並降低大規模的大量作業在大量交易期間，填滿可用交易記錄空間的可能性。 不過，如果資料庫在最低限度記錄生效時損毀或遺失，則您無法將資料庫復原到失敗點。

下列作業 (在完整復原模式下會完整記錄) 在簡單和大量記錄復原模式下會進行最低限度記錄：

  • 批量匯入操作（bcp、 BULK INSERT、 及 INSERT...SELECT）。 如需有關何時在資料表中進行大容量導入時的最小記錄的詳細資訊，請參閱 大容量導入中最小記錄的必要條件。

    備註

    啟用交易複製時， BULK INSERT 即使在批量記錄恢復模式下，操作也會被完整記錄。

  • SELECT INTO 操作。

    備註

    啟用事務複製時，即使大容量日誌恢復模式下，SELECT INTO 作業仍會完整記錄。

  • 對大值資料型態進行部分更新，使用 。在插入或附加新資料時，請在語句中 UPDATE 使用 WRITE 子句。 請注意，在更新現有值時，不會使用最低限度記錄。 如需大型實值資料類型的詳細資訊，請參閱 資料類型 （Transact-SQL） 。

  • 在使用WRITETEXT 和UPDATETEXT語句將新數據插入或附加至text、ntext和image資料類型數據行時。 請注意，在更新現有值時，不會使用最低限度記錄。

    備註

    WRITETEXT 和 UPDATETEXT 語句已被取代，因此您應該避免在新應用程式中使用這些語句。

  • 如果資料庫設定為簡單或大量記錄復原模式，則不管作業是離線執行或線上執行，某些索引 DDL 作業都是以最低限度的方式記錄。 以最低限度方式記錄的索引作業如下：

    • CREATE INDEX 操作（包括索引檢視）。

    • ALTER INDEX REBUILD 或 DBCC DBREINDEX 操作。

      備註

      DBCC DBREINDEX 語句已被取代，因此您應該避免在新應用程式中使用它。

    • DROP INDEX 新的堆重建（如適用）。

      備註

      在 DROP INDEX 作業期間，索引頁面的解除配置一律會完整記錄。

相關工作

Managing the transaction log

備份事務歷史記錄 （完整恢復模式）

還原事務歷史記錄檔 （完整恢復模式）

另請參閱

控制交易持久性
批量導入中最小記錄的必要條件
SQL Server 資料庫的備份與還原
資料庫檢查點 (SQL Server)
檢視或變更資料庫的屬性
復原模式 (SQL Server)

  • 上次更新時間：