事務日志(Transaction logs)是數(shù)據(jù)庫結構中非常重要但又經(jīng)常被忽略的部分。由于它并不像數(shù)據(jù)庫中的schema那樣活躍，因此很少有人關注事務日志。

　　事務日志是針對數(shù)據(jù)庫改變所做的記錄，它可以記錄針對數(shù)據(jù)庫的任何操作，并將記錄結果保存在獨立的文件中。對于任何每一個事務過程，事務日志都有非常全面的記錄，根據(jù)這些記錄可以將數(shù)據(jù)文件恢復成事務前的狀態(tài)。從事務動作開始，事務日志就處于記錄狀態(tài)，事務過程中對數(shù)據(jù)庫的任何操作都在記錄范圍，直到用戶點擊提交或后退后才結束記錄。每個數(shù)據(jù)庫都擁有至少一個事務日志以及一個數(shù)據(jù)文件。

　　出于性能上的考慮，SQL Server將用戶的改動存入緩存中，這些改變會立即寫入事務日志，但不會立即寫入數(shù)據(jù)文件。事務日志會通過一個標記點來確定某個事務是否已將緩存中的數(shù)據(jù)寫入數(shù)據(jù)文件。當SQL Server重啟后，它會查看日志中最新的標記點，并將這個標記點后面的事務記錄抹去，因為這些事務記錄并沒有真正的將緩存中的數(shù)據(jù)寫入數(shù)據(jù)文件。這可以防止那些中斷的事務修改數(shù)據(jù)文件。

　　維護事務日志

　　因為很多人經(jīng)常遺忘事務日志，因此它也會給系統(tǒng)帶來一些問題。隨著系統(tǒng)的不斷運行，日志記錄的內(nèi)容會越來越多，日志文件的體積也會越來越大，最終導致可用磁盤空間不足。除非日常工作中經(jīng)常對日志進行清理，否則日志文件最終會侵占分區(qū)內(nèi)的全部可用空間。日志的默認配置為不限容量，如果以這種配置工作，它就會不斷膨脹，最終也會占據(jù)全部可用空間。這兩種情況都會導致數(shù)據(jù)庫停止工作。

　　對事務日志的日常備份工作可以有效的防止日志文件過分消耗磁盤空間。備份過程會將日志中不再需要的部分截除。截除的方法是首先把舊記錄標記為非活動狀態(tài)，然后將新日志覆蓋到舊日志的位置上，這樣就可以防止事務日志的體積不斷膨脹。如果無法對日志進行經(jīng)常性的備份工作，最好將數(shù)據(jù)庫設置為"簡單恢復模式"。在這種模式下，系統(tǒng)會強制事務日志在每次記錄標記點時，自動進行截除操作，以新日志覆蓋舊日志。

　　截除過程發(fā)生在備份或將舊標記點標為非活動狀態(tài)時，它使得舊的事務記錄可以被覆蓋，但這并不會減少事務日志實際占用的磁盤空間。就算不再使用日志，它依然會占據(jù)一定的空間。因此在維護時，還需要對事務日志進行壓縮。壓縮事務日志的方法是刪除非活動記錄，從而減少日志文件所占用的物理硬盤空間。

　　通過使用DBCC SHRINKDATABASE語句可以壓縮當前數(shù)據(jù)庫的事務日志文件，DBCC SHRINKFILE語句用來壓縮指定的事務日志文件，另外也可以在數(shù)據(jù)庫中激活自動壓縮操作。當壓縮日志時，首先會將舊記錄標記為非活動狀態(tài)，然后將帶有非活動標記的記錄徹底刪除。根據(jù)所使用的壓縮方式的不同，你可能不會立即看到結果。在理想情況下，壓縮工作應該選在系統(tǒng)不是非常繁忙的時段進行，否則有可能影響數(shù)據(jù)庫性能。

　　恢復數(shù)據(jù)庫

　　事務記錄備份可以用來將數(shù)據(jù)庫恢復到某一指定狀態(tài)，但事務記錄備份本身不足以完成恢復數(shù)據(jù)庫的任務，還需要備份的數(shù)據(jù)文件參與恢復工作�；謴蛿�(shù)據(jù)庫時，首先進行的是數(shù)據(jù)文件的恢復工作。在整個數(shù)據(jù)文件恢復完成前，不要將其設為完成狀態(tài)，否則事務日志就不會被恢復。當數(shù)據(jù)文件恢復完成，系統(tǒng)會通過事務日志的備份將數(shù)據(jù)庫恢復成用戶希望的狀態(tài)。如果在數(shù)據(jù)庫最后一次備份后，存在多個日志文件的備份，備份程序會按照它們建立的時間依次將其恢復。

　　另一種被稱為log shipping的過程可以提供更強的數(shù)據(jù)庫備份能力。當log shipping配置好后，它可以將數(shù)據(jù)庫整個復制到另一臺服務器上。在這種情況下，事務日志也會定期發(fā)送到備份服務器上供恢復數(shù)據(jù)使用。這使得服務器一直處于熱備份狀態(tài)，當數(shù)據(jù)發(fā)生改變時它也隨之更新。另一個服務器被稱作監(jiān)視(monitor)服務器，可以用來監(jiān)視按規(guī)定時間間隔發(fā)送的shipping信號。如果在規(guī)定時間內(nèi)沒有收到信號，監(jiān)視服務器會將這一事件記錄到事件日志。這種機制使得log shipping經(jīng)常成為災難恢復計劃中使用的方案。

　　性能優(yōu)化

　　事務日志對數(shù)據(jù)庫有重要作用，同時它對系統(tǒng)的整體性能也有一定影響。通過幾個選項，我們可以對事務日志的性能進行優(yōu)化。由于事務日志是一個連續(xù)的磁盤寫入過程，在這當中不會發(fā)生讀取動作。因此將日志文件放在一個獨立的磁盤，對優(yōu)化性能有一定作用。

　　另一項優(yōu)化措施與日志文件的體積有關。我們可以設置日志文件的體積不超過硬盤空間的百分之幾，或者確定它的大小。如果將其設置的過大會浪費磁盤空間，而如果設置的過小則會強制記錄文件不斷嘗試擴展，導致數(shù)據(jù)庫性能下降。

　　事務日志文件Transaction Log File是用來記錄數(shù)據(jù)庫更新情況的文件，擴展名為ldf。

　　在 SQL Server 7.0 和 SQL Server 2000 中，如果設置了自動增長功能，事務日志文件將會自動擴展。

　　一般情況下，在能夠容納兩次事務日志截斷之間發(fā)生的最大數(shù)量的事務時，事務日志的大小是穩(wěn)定的，事務日志截斷由檢查點或者事務日志備份觸發(fā)。

　　然而，在某些情況下，事務日志可能會變得非常大，以致用盡空間或變滿。通常，在事務日志文件占盡可用磁盤空間且不能再擴展時，您將收到如下錯誤消息：

　　Error:9002, Severity:17, State:2

　　The log file for database ''%.*ls'' is full.

　　除了出現(xiàn)此錯誤消息之外，SQL Server 還可能因為缺少事務日志擴展空間而將數(shù)據(jù)庫標記為 SUSPECT。有關如何從此情形中恢復的其他信息，請參見 SQL Server 聯(lián)機幫助中的“磁盤空間不足”主題。

　　另外，事務日志擴展可能導致下列情形：

　　· 非常大的事務日志文件。

　　· 事務可能會失敗并可能開始回滾。

　　· 事務可能會用很長時間才能完成。

　　· 可能發(fā)生性能問題。

　　· 可能發(fā)生阻塞現(xiàn)象。

　　原因

　　事務日志擴展可能由于以下原因或情形而發(fā)生：

　　· 未提交的事務

　　· 非常大的事務

　　· 操作：DBCC DBREINDEX 和 CREATE INDEX

　　· 在從事務日志備份還原時

　　· 客戶端應用程序不處理所有結果

　　· 查詢在事務日志完成擴展之前超時，您收到假的“Log Full”錯誤消息

　　· 未復制的事務

　　解決方法:

　　日志文件滿而造成SQL數(shù)據(jù)庫無法寫入文件時，可用兩種方法：

　　一種方法：清空日志。

　　1.打開查詢分析器，輸入命令

　　DUMP TRANSACTION 數(shù)據(jù)庫名 WITH NO_LOG

　　2.再打開企業(yè)管理器右鍵你要壓縮的數(shù)據(jù)庫所有任務收縮數(shù)據(jù)庫收縮文件選擇日志文件在收縮方式里選擇收縮至XXM,這里會給出一個允許收縮到的最小M數(shù),直接輸入這個數(shù),確定就可以了。

　　另一種方法有一定的風險性，因為SQL SERVER的日志文件不是即時寫入數(shù)據(jù)庫主文件的，如處理不當，會造成數(shù)據(jù)的損失。

　　1.分離數(shù)據(jù)庫 企業(yè)管理器->服務器->數(shù)據(jù)庫->右鍵->分離數(shù)據(jù)庫

　　2：刪除LOG文件

　　附加數(shù)據(jù)庫 企業(yè)管理器->服務器->數(shù)據(jù)庫->右鍵->附加數(shù)據(jù)庫

　　此法生成新的LOG，大小只有500多K。

　　注意：建議使用第一種方法。

　　如果以后,不想要它變大。

　　SQL2000下使用：

　　在數(shù)據(jù)庫上點右鍵->屬性->選項->故障恢復-模型-選擇-簡單模型。

　　或用SQL語句：

　　alter database 數(shù)據(jù)庫名 set recovery simple

　　另外，如上圖中數(shù)據(jù)庫屬性有兩個選項，與事務日志的增長有關：

　　Truncate log on checkpoint

　　(此選項用于SQL7.0，SQL 2000中即故障恢復模型選擇為簡單模型)

　　當執(zhí)行CHECKPOINT 命令時如果事務日志文件超過其大小的70% 則將其內(nèi)容清除在開發(fā)數(shù)據(jù)庫時時常將此選項設置為True Auto shrink定期對數(shù)據(jù)庫進行檢查當數(shù)據(jù)庫文件或日志文件的未用空間超過其大小的25%時，系統(tǒng)將會自動縮減文件使其未用空間等于25% 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減后的文件也必須大于或等于其初始大小對事務日志文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行。

　　注意：一般立成建立的數(shù)據(jù)庫默認屬性已設好，但碰到意外情況使數(shù)據(jù)庫屬性被更改，請用戶清空日志后，檢查數(shù)據(jù)庫的以上屬性，以防事務日志再次充滿。