原文：http://blog.csdn.net/tjvictor/article/details/5253931
當SQL Server截斷事務日誌時，它僅僅是在虛擬日誌檔案中做個標記，以便不再使用它，然後準備以重用形式來做備份(假如運載在完整或是批量日誌恢復模型)。也就是說，在使用簡單恢復模型時，事務日誌包括如下的日誌記錄：
當checkpoint發生時，虛擬日誌檔案1、2不再被使用，因為事務1、2已經被提交了，而且日誌記錄也不再需要回滾了。然後SQL Server重用虛擬日誌檔案1、2，如下圖：
這就是我們所熟知的事務日誌截斷。基本上，事務日誌的活動區間已經被截斷了，但是事務日誌的物理大小不會改變，除非資料庫使用自動收縮的屬性設定。在這種情況下，事務日誌就會盡可能的在物理上進行週期性的收縮。
為了物理上減小事務日誌的大小，收縮事務日誌作為已知的方法，你在使用時可以選擇下面選項中的一種：
- 執行 DBCC SHRINKDATABASE命令
- 執行 DBCC SHRINKFILE命令
- 設定資料庫的事務日誌自動收縮選項
需要注意的是，事務日誌僅僅能收縮到虛擬日誌檔案的邊界。下面是個例子。
我新建了一個資料庫，它有1MB的事務日誌空間，5MB的自動增長空間。執行DBCC LOGINFO顯示如下：
這裡有四個可變大小的虛擬日誌檔案。然後我輸入一些資料，這會使事務日誌 增長到5MB：
在新的5MB事務日誌區間裡面新建了4個新的虛擬日誌檔案。每一個新建的虛擬日誌檔案都是1310720bytes，每7個虛擬日誌檔案正在使用時(狀態是2)。我現在備份事務日誌，因此將會截斷事務日誌：
目前僅僅有一個虛擬日誌檔案在使用(第7行，狀態為2). 假如我現在用下面的命令，試著把日誌收縮到2M：
DBCC SHRINKFILE ('AdventureWorks_log', 2)
因為活動日誌記錄是虛擬日誌檔案7，所以SQL Server僅僅刪除虛擬日誌檔案8。這次事務日誌從7MB收縮到4.7MB. SQL Server也在事務日誌中新建了假的入口，為了移除2MB點之前的最近活動日誌記錄，以便於它包裹到虛擬日誌檔案2（注意狀態為2的行）。
假如現在再次備份事務日誌的話，事務日誌會再次被截斷，現在活動區間就是虛擬日誌檔案2了。
如果我現在再嘗試一次收縮檔案的話，SQL Server則會成功的收縮到2MB左右，因為日誌的活動區間已經接近2MB了。檔案被收縮到最接近於日誌登記時的大小。這時DBCC LOGINFO的輸出如下：
事務日誌檔案大小為2359296bytes(虛擬日誌檔案大小總量要加上8192位元組的頭資訊)
所以如果你發現你不能收縮事務日誌到一個指定的範圍，執行DBCC LOGINFO，然後檢查虛擬日誌檔案的範圍，弄清楚每一個日誌的大小，你能把檔案收縮到什麼範圍。
本文翻譯自sqlbackuprestore，更多精彩內容請瀏覽http://www.sqlbackuprestore.com