適用於：
SQL Server
每個 SQL Server 資料庫都擁有交易記錄來記錄所有交易，以及交易在資料庫中所作的修改。
交易記錄是資料庫的重要元件。 如果發生系統故障，您需要此日誌才能將資料庫恢復到一致的狀態。
警告
永遠不要刪除或移動此記錄檔，除非您完全了解這麼做的後果。
如需交易記錄的實體和邏輯架構的相關資訊，請參閱 SQL Server 交易記錄檔架構和管理指南。
提示
檢查點會建立已知的良好點，以便在資料庫復原期間開始套用交易記錄。 如需詳細資訊，請參閱資料庫檢查點 (SQL Server)。
交易記錄所支援的作業
交易記錄檔支援下列作業：
- 個別交易的復原。
- 在 SQL Server 啟動時復原所有未完成的交易。
- 將還原的資料庫、檔案、檔案群組或頁面向前復原到失敗點。
- 支援異動複寫。
- 支援高可用性和災害復原解決方案：Always On 可用性群組、資料庫鏡像和記錄傳送。
個別交易復原
如果應用程式發出一個 ROLLBACK 陳述式，或 Database Engine 偵測到與用戶端的通訊中斷等錯誤，記錄檔記錄可用來回復未完成之交易所作的修改。
在 SQL Server 啟動時復原所有未完成的交易
如果伺服器失敗，資料庫的狀態可能停留於緩衝區快取中有些修改尚未寫入資料檔中，並且未完成的交易已在資料檔中作了一些修改。 當啟動 SQL Server 執行個體時，它會在每個資料庫上執行復原。 已記錄於記錄中、但尚未寫入資料檔中的每個修改將會向前復原。 將會回復交易記錄檔中所發現的每筆未完成交易，以確保資料庫的完整性。 如需詳細資訊，請參閱還原和復原概觀 （SQL Server）。
將還原的資料庫、檔案、檔案群組或頁面向前復原到失敗點
在硬體損毀或磁碟失敗影響資料庫檔案後，您可以將資料庫還原至失敗點。 請先還原最後一次的完整資料庫備份和最後一次的差異資料庫備份，然後將後續一連串的交易記錄備份還原到失敗點。
在還原每個記錄檔備份時，Database Engine 會重新套用記錄在記錄檔中的所有修改，以向前復原所有交易。 在還原最後一個記錄檔備份後，資料庫引擎接著會使用記錄檔資訊來回復在該點尚未完成的所有交易。 如需詳細資訊，請參閱還原和復原概觀 （SQL Server）。
支援異動複寫
「記錄讀取器代理程式」會監視設定異動複寫的各資料庫交易記錄，並將標示要複寫的交易從交易記錄複製到散發資料庫中。 如需詳細資訊，請參閱 交易式複寫的運作方式。
支援高可用性和災害復原解決方案
待命伺服器解決方案、Always On 可用性群組、資料庫鏡像和記錄傳送均高度依賴交易記錄。
在 Always On 可用性群組案例中，主要複本上資料庫的每個更新都會立即在所有次要複本上資料庫的單獨複本中重製。 主要複本會立即將每個記錄檔記錄傳送至次要複本，而它會將收到的記錄檔記錄套用到可用性資料庫，以持續向前復原。 如需詳細資訊，請參閱 Always On 容錯移轉叢集執行個體 (SQL Server)。
在記錄傳送案例中，主要伺服器會將主要資料庫的交易記錄備份傳送至一或多個目的地。 每個次要伺服器都會將記錄備份還原至其本機次要資料庫。 如需詳細資訊，請參閱關於記錄傳送 (SQL Server)。
在資料庫鏡像案例中，主體資料庫的每個更新都會立即在另一個完整的個別資料庫複本 (鏡像資料庫) 中重製。 主體伺服器執行個體會立即傳送每個記錄檔記錄到鏡像伺服器執行個體，而它會將傳入的記錄檔記錄套用至鏡像資料庫，以持續向前復原。 如需詳細資訊，請參閱資料庫鏡像 （SQL Server）。
交易記錄特性
SQL Server 資料庫引擎交易記錄的特性：
交易記錄是實作成資料庫中的個別檔案或一組檔案。 日誌快取與資料頁的緩衝區快取分開管理。 這種分離會導致 SQL Server 資料庫引擎內產生簡單、快速且健全的程式碼。 如需詳細資訊，請參閱 交易記錄實體架構。
記錄檔記錄與頁面的格式並不一定要遵照資料頁的格式。
交易記錄檔可實作於多個檔案上。 您可以設定
FILEGROWTH記錄檔的值，將檔案設定為自動展開。 此配置可減少交易日誌中空間不足的可能性，同時減少管理額外負擔。 如需詳細資訊，請參閱 ALTER DATABASE （Transact-SQL） 檔案和檔案群組選項。重複使用記錄檔空間的機制很迅速，並對於交易輸送量的影響很小。
如需交易記錄的實體和邏輯架構的相關資訊，請參閱 SQL Server 交易記錄檔架構和管理指南。
交易記錄截斷
記錄截斷會釋出記錄檔中的空間，以供交易記錄重複使用。 您必須定期截斷交易記錄，以防止它填滿所分配的空間。 有數種因素會延遲記錄的截斷，所以監控記錄大小很重要。 某些作業可以記錄最少，以減少其對交易記錄大小的影響。
記錄截斷會從 SQL Server 資料庫的邏輯交易記錄檔中刪除非作用中的 虛擬記錄檔 （VLF）， 釋放邏輯記錄檔中的空間，以供實體交易記錄重複使用。 如果永遠都不截斷交易記錄，最終將會填滿分配給實體記錄檔的所有磁碟空間。
為了避免用盡空間，除非記錄截斷因為某個原因而延遲，否則將在以下事件後自動進行截斷：
在簡單復原模式下，發生在檢查點之後。
在完整復原模式或大量記錄復原模式下，如果上一次備份之後已產生檢查點，則截斷會發生在記錄備份之後 (除非它是只複製的記錄備份)。
當您第一次建立使用完整復原模式的資料庫時，交易記錄會視需要重複使用 （類似於使用簡單復原模式的資料庫），直到您建立完整資料庫備份為止。
如需詳細資訊，請參閱本文稍後的 可能延遲記錄截斷的因素 。
記錄截斷並不會讓實體記錄檔變小。 若要減少實體記錄檔的實體大小，則必須壓縮記錄檔。 如需有關壓縮實體記錄檔大小的詳細資訊，請參閱管理交易記錄檔的大小。 但是，請記住 可能延遲日誌截斷的因素。 如果在記錄壓縮之後再次需要儲存空間，交易記錄會再次成長，而且這樣做會在記錄成長作業期間造成效能額外負荷。
可能會延遲記錄截斷的因素
當記錄記錄長時間保持作用中時，交易記錄截斷會延遲，而且交易記錄可能會填滿，如本文稍早所述。
重要
如需如何回應完整交易記錄的相關資訊，請參閱針對完整交易記錄進行疑難排解 （SQL Server 錯誤 9002）。
記錄截斷可能會因為各種原因而延遲。 若要瞭解阻止記錄截斷的原因，請查詢 log_reuse_wait 目錄檢視 log_reuse_wait_desc 和 資料行。 下表描述這些資料行的值。
| 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 複寫。 |
7 |
DATABASE_SNAPSHOT_CREATION |
正在建立資料庫快照。 （所有復原模型。 這是延遲記錄截斷的一般原因 (通常也是暫時的原因)。 |
8 |
LOG_SCAN |
正在進行日誌掃描。 （所有復原模型。 這是延遲記錄截斷的一般原因 (通常也是暫時的原因)。 |
9 |
AVAILABILITY_REPLICA |
可用性群組的次要複本正在將這個資料庫的交易記錄檔記錄套用到對應的次要資料庫。 （僅限完整復原模型。 如需詳細資訊，請參閱什麼是 Always On 可用性群組？。 |
10 |
- | 僅限內部使用。 |
11 |
- | 僅限內部使用。 |
12 |
- | 僅限內部使用。 |
13 |
OLDEST_PAGE |
如果將資料庫設定為使用間接檢查點，資料庫中最舊的頁面可能會比檢查點記錄序號 (LSN) 更舊。 在此情況下，最舊的頁面可能會延遲日誌截斷。 （所有復原模型。 如需間接檢查點的相關資訊，請參閱資料庫檢查點 (SQL Server)。 |
14 |
OTHER_TRANSIENT |
這個值目前尚未使用。 |
16 |
XTP_CHECKPOINT |
需要執行記憶體內部 OLTP 檢查點。 對於記憶體最佳化資料表，當交易記錄檔自上次檢查點以來大於 1.5 GB 時，會採取自動檢查點。 （包括磁碟型和記憶體最佳化資料表。 如需詳細資訊，請參閱 記憶體最佳化資料表的檢查點作業 和 記憶體最佳化資料表的記錄和檢查點程序。 |
可以進行最低限度記錄的作業
最小記錄 牽涉到只記錄復原交易所需的資訊，而不支援時間點復原。 本文會識別大量記錄復 原模型 （以及簡單復原模型下，除非備份正在執行） ，否則會以最低限度記錄的作業。
記憶體最佳化資料表不支援最低限度記錄。
在完整 復原模式下，將完整記錄所有大量作業。 不過，您可以暫時針對大量作業，將資料庫切換成大量記錄復原模式，藉以將大量作業集的記錄降至最低。 最低限度記錄會比完整記錄更具效率，並降低大規模的大量作業在大量交易期間，填滿可用交易記錄空間的可能性。 然而，如果資料庫在最低限度記錄作用時損毀或遺失，您就無法將資料庫復原至失敗點。
下列作業 (在完整復原模式下會完整記錄) 在簡單和大量記錄復原模式下會進行最低限度記錄：
大量匯入作業 (bcp、BULK INSERT 與 INSERT)。 如需何時大量匯入至資料表會採用最低限度記錄的詳細資訊，請參閱大量匯入中最低限度記錄的必要條件。
啟用交易式複寫時，
BULK INSERT即使在大量記錄復原模型下，作業也會完全記錄。-
啟用交易式複寫時，
SELECT INTO即使在大量記錄復原模型下，作業也會完全記錄。 插入或附加新資料時，在
.WRITE陳述式中使用 子句，對大數值資料類型執行的部分更新。 當更新現有值時，不會使用最低限度記錄。 如需關於大型值資料類型的詳細資訊，請參閱資料類型。將新的資料插入或附加至 text、ntext 及 image 資料類型資料行時的 WRITETEXT 和 UPDATETEXT 陳述式。 當更新現有值時，不會使用最低限度記錄。
警告
and
WRITETEXTUPDATETEXT陳述式已被取代。 避免在新應用程式中使用它們。如果資料庫設定為簡單或大量記錄復原模式，則不論作業是離線或線上執行，都會記錄某些索引 DDL 作業。 最低記錄的索引作業包括：
CREATE INDEX 作業 (包括索引檢視表)。
ALTER INDEX REBUILD 或
DBCC DBREINDEX作業。索引建置作業會使用最少的記錄，但當有同時執行的備份時，可能會延遲。 此延遲是由於當您使用簡式或大量記載復原模式時，最低記錄緩衝池頁面的同步化需求所造成。
警告
此
DBCC DBREINDEX陳述式已取代。 避免在新的應用程式中使用它。DROP INDEX 新堆積重建 (如果適用)。 作業期間
DROP INDEX的索引頁面解除配置一律會完整記載。
相關工作
| Task | 發行項 |
|---|---|
| 管理交易記錄 |
管理交易記錄檔的大小 針對完整交易記錄進行疑難排解 （SQL Server 錯誤 9002） |
| 備份交易記錄 (僅限完整復原模式) |
備份交易記錄 資料庫損毀時備份交易記錄檔 （SQL Server） |
| 還原交易記錄 (僅限完整復原模式) | 還原交易記錄備份 （SQL Server） |