sql server日誌檔案總結及日誌滿的處理辦法

交易日誌（Transaction logs）是資料庫結構中非常重要但又經常被忽略的部分。由於它並不像資料庫中的schema那樣活躍，因此很少有人關注交易日誌。

交易日誌是針對資料庫改變所做的記錄，它可以記錄針對資料庫的任何操作，並將記錄結果儲存在獨立的檔案中。對於任何每一個交易過程，交易日誌都有非常全面的記錄，根據這些記錄可以將資料檔案恢復成交易前的狀態。從交易動作開始，交易日誌就處於記錄狀態，交易過程中對資料庫的任何操作都在記錄範圍，直到使用者點選提交或後退後才結束記錄。每個資料庫都擁有至少一個交易日誌以及一個資料檔案。

出於效能上的考慮，SQL Server將使用者的改動存入快取中，這些改變會立即寫入交易日誌，但不會立即寫入資料檔案。交易日誌會透過一個標記點來確定某個交易是否已將快取中的資料寫入資料檔案。當SQL Server重啟後，它會檢視日誌中最新的標記點，並將這個標記點後面的交易記錄抹去，因為這些交易記錄並沒有真正的將快取中的資料寫入資料檔案。這可以防止那些中斷的交易修改資料檔案。
　　

維護交易日誌

因為很多人經常遺忘交易日誌，因此它也會給系統帶來一些問題。隨著系統的不斷執行，日誌記錄的內容會越來越多，日誌檔案的體積也會越來越大，最終導致可用磁碟空間不足。除非日常工作中經常對日誌進行清理，否則日誌檔案最終會侵佔分割槽內的全部可用空間。日誌的預設配置為不限容量，如果以這種配置工作，它就會不斷膨脹，最終也會佔據全部可用空間。這兩種情況都會導致資料庫停止工作。

對交易日誌的日常備份工作可以有效的防止日誌檔案過分消耗磁碟空間。備份過程會將日誌中不再需要的部分截除。截除的方法是首先把舊記錄標記為非活動狀態，然後將新日誌覆蓋到舊日誌的位置上，這樣就可以防止交易日誌的體積不斷膨脹。如果無法對日誌進行經常性的備份工作，最好將資料庫設定為"簡單恢復模式"。在這種模式下，系統會強制交易日誌在每次記錄標記點時，自動進行截除操作，以新日誌覆蓋舊日誌。

截除過程發生在備份或將舊標記點標為非活動狀態時，它使得舊的交易記錄可以被覆蓋，但這並不會減少交易日誌實際佔用的磁碟空間。就算不再使用日誌，它依然會佔據一定的空間。因此在維護時，還需要對交易日誌進行壓縮。壓縮交易日誌的方法是刪除非活動記錄，從而減少日誌檔案所佔用的物理硬碟空間。

透過使用DBCC SHRINKDATABASE語句可以壓縮當前資料庫的交易日誌檔案，DBCC SHRINKFILE語句用來壓縮指定的交易日誌檔案，另外也可以在資料庫中啟用自動壓縮操作。當壓縮日誌時，首先會將舊記錄標記為非活動狀態，然後將帶有非活動標記的記錄徹底刪除。根據所使用的壓縮方式的不同，你可能不會立即看到結果。在理想情況下，壓縮工作應該選在系統不是非常繁忙的時段進行，否則有可能影響資料庫效能。

恢復資料庫

交易記錄備份可以用來將資料庫恢復到某一指定狀態，但交易記錄備份本身不足以完成恢復資料庫的任務，還需要備份的資料檔案參與恢復工作。恢復資料庫時，首先進行的是資料檔案的恢復工作。在整個資料檔案恢復完成前，不要將其設為完成狀態，否則交易日誌就不會被恢復。當資料檔案恢復完成，系統會透過交易日誌的備份將資料庫恢復成使用者希望的狀態。如果在資料庫最後一次備份後，存在多個日誌檔案的備份，備份程式會按照它們建立的時間依次將其恢復。

另一種被稱為log shipping的過程可以提供更強的資料庫備份能力。當log shipping配置好後，它可以將資料庫整個複製到另一臺伺服器上。在這種情況下，交易日誌也會定期傳送到備份伺服器上供恢復資料使用。這使得伺服器一直處於熱備份狀態，當資料發生改變時它也隨之更新。另一個伺服器被稱作監視（monitor）伺服器，可以用來監視按規定時間間隔傳送的shipping訊號。如果在規定時間內沒有收到訊號，監視伺服器會將這一事件記錄到事件日誌。這種機制使得log shipping經常成為災難恢復計劃中使用的方案。

效能最佳化

交易日誌對資料庫有重要作用，同時它對系統的整體效能也有一定影響。透過幾個選項，我們可以對交易日誌的效能進行最佳化。由於交易日誌是一個連續的磁碟寫入過程，在這當中不會發生讀取動作。因此將日誌檔案放在一個獨立的磁碟，對最佳化效能有一定作用。

另一項最佳化措施與日誌檔案的體積有關。我們可以設定日誌檔案的體積不超過硬碟空間的百分之幾，或者確定它的大小。如果將其設定的過大會浪費磁碟空間，而如果設定的過小則會強制記錄檔案不斷嘗試擴充套件，導致資料庫效能下降。
　　
　　事務日誌檔案Transaction Log File是用來記錄資料庫更新情況的檔案，副檔名為ldf。
　　在 SQL Server 7.0 和 SQL Server 2000 中，如果設定了自動增長功能，事務日誌檔案將會自動擴充套件。
　　一般情況下，在能夠容納兩次事務日誌截斷之間發生的最大數量的事務時，事務日誌的大小是穩定的，事務日誌截斷由檢查點或者事務日誌備份觸發。
　　然而，在某些情況下，事務日誌可能會變得非常大，以致用盡空間或變滿。通常，在事務日誌檔案佔盡可用磁碟空間且不能再擴充套件時，您將收到如下錯誤訊息：
　　Error:9002, Severity:17, State:2
　　The log file for database ’%.*ls’ is full.
　　除了出現此錯誤訊息之外，SQL Server 還可能因為缺少事務日誌擴充套件空間而將資料庫標記為 SUSPECT。有關如何從此情形中恢復的其他資訊，請參見 SQL Server 聯機幫助中的“磁碟空間不足”主題。
　　
　　另外，事務日誌擴充套件可能導致下列情形：
　　· 非常大的事務日誌檔案。
　　· 事務可能會失敗並可能開始回滾。
　　· 事務可能會用很長時間才能完成。
　　· 可能發生效能問題。
　　· 可能發生阻塞現象。
　　
　　原因
　　事務日誌擴充套件可能由於以下原因或情形而發生：
　　· 未提交的事務
　　· 非常大的事務
　　· 操作：DBCC DBREINDEX 和 CREATE INDEX
　　· 在從事務日誌備份還原時
　　· 客戶端應用程式不處理所有結果
　　· 查詢在事務日誌完成擴充套件之前超時，您收到假的“Log Full”錯誤訊息
　　· 未複製的事務
　　
　　解決方法
　　日誌檔案滿而造成SQL資料庫無法寫入檔案時，可用兩種方法：
　　一種方法：清空日誌。
　　1．開啟查詢分析器，輸入命令
　　DUMP TRANSACTION 資料庫名 WITH NO_LOG
　　2.再開啟企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮檔案--選擇日誌檔案--在收縮方式裡選擇收縮至XXM,這裡會給出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。
　　
　　另一種方法有一定的風險性，因為SQL SERVER的日誌檔案不是即時寫入資料庫主檔案的，如處理不當，會造成資料的損失。
　　1: 刪除LOG
　　分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫
　　2：刪除LOG檔案
　　附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫
　　此法生成新的LOG，大小隻有500多K。
　　
　　注意：建議使用第一種方法。
　　
　　如果以後,不想要它變大。
　　SQL2000下使用：
　　在資料庫上點右鍵->屬性->選項->故障恢復-模型-選擇-簡單模型。
　　或用SQL語句：
　　alter database 資料庫名 set recovery simple
　　
　　
　　另外，如上圖中資料庫屬性有兩個選項，與事務日誌的增長有關：
　　Truncate log on checkpoint
　　(此選項用於SQL7.0，SQL 2000中即故障恢復模型選擇為簡單模型)
　　當執行CHECKPOINT 命令時如果事務日誌檔案超過其大小的70% 則將其內容清除在開發資料庫時時常將此選項設定為True
　　Auto shrink
　　定期對資料庫進行檢查當資料庫檔案或日誌檔案的未用空間超過其大小的25%時，系統將會自動縮減檔案使其未用空間等於25% 當檔案大小沒有超過其建立時的初始大小時不會縮減檔案縮減後的檔案也必須大於或等於其初始大小對事務日誌檔案的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行。
　　
　　
　　注意：一般立成建立的資料庫預設屬性已設好，但碰到意外情況使資料庫屬性被更改，請使用者清空日誌後，檢查資料庫的以上屬性，以防事務日誌再次充滿。