SQL Server如何截斷(Truncate)和收縮(Shrink)事務日誌

當SQL Server截斷事務日誌時，它僅僅是在虛擬日誌文件中作個標記，以便再也不使用它，而後準備以重用形式來作備份(假如運載在完整或是批量日誌恢復模型)。也就是說，在使用簡單恢復模型時，事務日誌包括以下的日誌記錄： 

 當checkpoint發生時，虛擬日誌文件一、2再也不被使用，由於事務一、2已經被提交了，並且日誌記錄也再也不須要回滾了。而後SQL Server重用虛擬日誌文件一、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，而後檢查虛擬日誌文件的範圍，弄清楚每個日誌的大小，你能把文件收縮到什麼範圍。