SQL Server如何截斷(Truncate)和收縮(Shrink)交易記錄

標籤：

原文：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

SQL Server如何截斷(Truncate)和收縮(Shrink)交易記錄