一、日誌截斷的目的
　　日誌截斷後，數據庫引擎將MinLSN之前的虛擬日誌文件（VLF）標記為“可復用”。“可復用”的VLF可以成為日誌回繞後重復利用的空間，也可以在收縮日誌文件時釋放其占用的磁盤空間。詳情已經在第五章討論過。
　　如果日誌文件不能被截斷，為了能寫入後續的事務日誌，數據庫引擎將為日誌文件（ldf）申請更多的磁盤空間。因此，將導致日誌文件持續增長。

二、阻礙日誌截斷的常見原因
1. 未提交的事務
　　如果不發出顯式 COMMIT 或 ROLLBACK 命令，顯式事務將不提交。這種情況最常發生在應用程序發出了 CANCEL 或 T-SQL 的 KILL 命令但未發出對應的 ROLLBACK 命令時。這時會發生事務取消，但不回退；這樣，SQL Server 將不能截斷此後發生的每一個事務，因為中止的事務仍處於打開狀態。
　　可以使用 DBCC OPENTRAN 來檢查在某一特定時間數據庫中是否有一個活動的事務。

2. 非常大的事務
　　事務日誌文件中的日誌記錄的截斷是逐個事務進行的。如果事務的範圍較大，此事務和任何在其後開始的事務只有在此事務完成後才能從事務日誌中被刪除。這可能會導致較大的日誌文件。如果事務大到一定程度，日誌文件就可能會用盡可用磁盤空間並導致“transaction log full”之類的錯誤消息（如 Error 9002）。

3. 需要日誌備份
　　完整恢復模式或大容量日誌恢復模式時，需要執行一次事務日誌備份才能截斷日誌。
4. 尚未出現檢查點
　　簡單恢復模式時，等待一個CHECKPOINT。
5. 未復制的事務
　　完整恢復模式時，如果數據庫處於鏡像、事務復制狀態，如果事務日誌同步發生的延遲，那麽可能會導致源數據庫的日誌不能被截斷。

三、查看不能截斷日誌的原因
運行以下語句，查看日誌不能截斷的原因。

SELECT log_reuse_wait , log_reuse_wait_desc FROM sys.databases WHERE name=‘db01‘

根據返回的 log_reuse_wait 值和 log_reuse_wait_desc 描述，可以發現日誌不能截斷的原因。更多的說明，請參考《可能延遲日誌截斷的因素》

http://technet.microsoft.com/zh-cn/library/ms345414(v=sql.105).aspx

收縮日誌文件

一、收縮日誌的前提條件
1. 確保日誌已被截斷
　　只有日誌被截斷之後，日誌文件中的VLF被標記為“可復用”，這部分空間才可以被釋放，從而達到收縮日誌文件的目的。
2. 查看日誌文件的空間

3.收縮日誌文件的必要
一般情況下沒有收縮日誌文件的必要。通常僅在以下場景中需要收縮日誌文件：
（1）完整恢復模式時，由於日誌未能截斷（例如，長時間未執行事務日誌備份），導致日誌文件過度增長，即使在日誌被截斷後日誌文件也不會自動收縮（釋放磁盤空間），因此需要手動收縮日誌文件。
（2）執行大批量操作時（插入大量數據），日誌文件迅速增長，大批量操作結束後，日誌文件不會自動釋放空間，因此需要先截斷事務日誌然後再收縮日誌文件。

二、收縮日誌文件的方法
1. T-SQL
例如：
DBCC SHRINKFILE (N‘db01_log‘ , 0, TRUNCATEONLY)
註意：T-SQL語句中需要使用日誌文件的邏輯名稱。邏輯名稱可以在數據庫屬性中查找。

2. 圖形界面

（2.17）備份與還原--事務日誌不能截斷的原因與收縮日誌文件