有關事務日誌截斷和收縮

概述

在實際環境中，我們經常會遇到事務日誌滿，無法進行操作，這樣我們需要手動進行對日誌檔案的截斷和收縮。由於長時間執行的事務或暫停的資料庫映象會話都

可導致事務日誌填滿，這個時候日誌中的事務仍處理活動狀態，經常有人在右擊資料庫--&gttask--&gtshrink--&gtfiles，選擇資料庫檔案或日期志檔案都不產生效果。如果資料庫使用的是簡單恢復模式，事務日誌將被自動截斷。

 

首先，我們可以通過目錄檢視sys.databases中log_reuse_wait和log_reuse_wait_desc列可顯示事務日誌的活動情況：

 

SELECT name,log_reuse_wait,log_reuse_wait_desc FROM sys.databases

 

當log_reuse_wait_desc為ACTIVE_TRANSACTION時，表示事務日誌處於活動狀態，這時通過普通的收縮日期志檔案不會有效。

 

 

日誌截斷

日誌截斷可釋放日誌檔案中的空間，以供事務日誌重新使用。由於日誌的活動部分不能通過收縮來截斷或刪除，因此，當日志記錄長時間保持活動狀態時，截斷將被延遲。

 

日誌截斷（在簡單恢復模式下自動執行）對於防止日誌變滿至關重要。截斷過程通過將不包含任何邏輯日誌部分的虛擬日誌檔案標記為不活動來減小邏輯日誌檔案的大小。

 

日誌截斷並不減小物理日誌檔案的大小。 減小日誌檔案的物理大小需要收縮檔案。

 

在清除事務日誌，SQLSERVER 2000與SQLSERVER 2005基本上可以用一樣的命令，但是在SQLSERVER 2005有些新的變化。

 

SQLSERVER 2000

DUMP TRANSACTION { database_name | @database_name_var }

  WITH { NO_LOG | TRUNCATE_ONLY }

[;]

 

 

SQLSERVER 2005則可以用BACKUP命令完成

Backing Up the Transaction Log (full and bulk-logged recovery models)

BACKUP LOG { database_name | @database_name_var }

  TO [ ,...n ]

  [ ] [ next-mirror-to ]

  [ WITH { | } [ ,...n ] ]

[;]

 

Truncating the Transaction Log (breaks the log chain)

BACKUP LOG { database_name | @database_name_var }

  WITH { NO_LOG | TRUNCATE_ONLY }

[;]

 

注：SQL SERVER 2008 已取消BACKUP TRANSACTION、BACKUP LOG { WITH NO_LOG | TRUNCATE_ONLY } 功能

在SQL SERVER 2008中，如果資料庫使用的是簡單恢復模式，事務日誌將被自動截斷。如果必須從資料庫刪除日誌備份鏈，請切換到簡單恢復模式。

 

收縮日誌檔案

DBCC SHRINKFILE (N'filename_log' , 0, TRUNCATEONLY);

 

例：

在日誌的活動部分不能通過收縮來截斷或刪除時，將通過截斷後再收縮(SQL SERVER 2005)

1. BACKUP LOG database_name WITH TRUNCATE_ONLY

 

2.  DBCC SHRINKFILE (N'filename_log' , 0, TRUNCATEONLY);

 

即可完成！

 

在完成事務日誌截斷和收縮後，之後的差異備份和日期志備份將無效，所以要求做一次完全備份！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9932141/viewspace-631056/，如需轉載，請註明出處，否則將追究法律責任。