前面提到過了，他是霸占磁盤空間的罪魁禍首，有些管理員一看日志文件很多的時候，于是開始刪除日志文件，刪到后來覺得煩瑣了，于是就“啟用循環日志”來減少煩瑣的工作。我前面說了，你啟用這個功能的話，你就可以向上帝祈求了...

　　很多剛接觸Exchange的管理員會提出疑問：日志文件到底有什么用?是不是多余的?那我們來看看日志的重大作用。

　　對于一個SG來說，系統會產生一系列的日志，每個大小為5M，這些日志的擴展名為LOG，前綴一般是E00、E01……除了這些連續的日志文件外，還有一些特殊的日志文件(res1.log,res2.log,e0x.chk)，它們又有什么用呢?如果對Exchange數據做完全備份(Full Backup)的話，備份后日志文件會自動刪除的，然后重新產生。老實說，十個管理員有九個對備份工作都怕怕，因此對這些日志是痛恨不已啊。我自己也做系統管理，對數據備份這個麻煩的工作的確很感冒，但是說到最后：備份工作必須做!不得不做!話題好像扯遠了，呵呵...

　　那么微軟在Exchange數據庫系統中引入日志到底有什么作用呢?我們從以下幾個方面來考察一下日志的作用：

　　1、作為一個企業級的郵件系統，必須要保證數據安全和完整。必須能夠面對隨時可能發生的意外災難，把數據損失降低到最小。

　　2、必須提供高性能的郵件處理能力，對數據庫中的郵件的事務操作在完成后必須馬上(或是說立即)被記錄在存儲介質上(見前面的事務持久性說明)

　　3、災難發生后，使用數據庫備份恢復必須要返回到災難發生前一刻的數據庫狀態(這是至關重要的!)

　　現在我們來更進一步的看一下，當用戶要修改郵箱中的內容時，被修改的內容首先被提取出來放到內存中，實際的修改是發生在內存里的，這是眾所周知的，當修改完成后，這些內容必須被盡快寫回存儲介質，這樣才表示一個事務成功完成了。

　　從事務的描述中我們可以看到，事務是具有Atomic特性的，為了保證數據庫的一致和完整，事務必須全部成功或全部失敗，如果事務失敗，則必須回滾到事務開始的狀態。而當郵件在內存中修改完成后，此時事務并沒有完成，因為還沒有寫到磁盤上。一旦系統崩潰，這些修改就丟失了。所以要確保事務修改完成，必須盡快將修改寫回到數據庫里去(也就是硬盤上)，這也是事務的持久性要求。

　　注意，這里說的第一時間或是盡快，是一個什么樣的概念呢?如果我們直接修改EDB文件，由于EDB文件比較大，那么在硬盤上修改一個大文件，就需要花費大量的時間在等待和尋找數據存儲塊上(學過操作系統原理的人應該知道的)，當系統出現高負載的繁忙狀態時，這將是一個非常大的瓶頸，也就無法做到“盡快”了。那怎么辦呢?所以數據庫系統使用了日志文件，而日志文件只有5MB大小，向這些文件寫入修改肯定是很快速的，因此當內存的修改完成后，這些結果就會立即寫入日志中，以保證了事務的持久性。當成功寫入日志后，該事務就成功完成了(現在在硬盤上了，不會因為當機丟失了)接下來，ESE引擎會在后臺慢慢將這些日志里的修改記錄寫回真正的數據庫里去(這對用戶來說已經不是那么重要了,這時候可能你的郵件都已經到對方了)，這就是日志的第一個作用：確保事務在第一時間(盡可能快的)保存到非易失存儲器上(磁盤上)，提供了事務持久性支持。我自己是變相的把他理解為郵件數據緩存的，不知道這樣是否科學，呵呵!

　　根據上面的描述，我們看到運行中的Exchange數據庫，是由三個部分組成的：

　　* 內存中已經完成處理還沒有寫會到日志里的內容(Dirt page)

　　* 還沒有寫到數據庫文件里的日志內容

　　* EDB和STM數據庫文件

　　對于第一個部分(內存中的)，一旦掉電就會丟失的，是最不安全的。而對于第二部分的內容，系統通過檢查點文件(CHK)來標記哪些日志已經被寫入數據庫了，而哪些還沒有。CHK文件類似一個指針。我們可以用“ESEUTIL /MK”來檢查CHK文件里的內容，在該命令的輸出中的checkpoint:<0x8,26d1,29>這樣的東西就是檢查點位置，它表示E0x00008的日志的頁面序號已經被成功寫入數據庫了。大家可以自己看看。。：)

前面提到過，Exchange系統在出現災難時，應該能恢復到災難發生前時刻的狀態。這是非常重要的。我在最前面就說過了“我就不相信你有做到時時備份”，但即使是最勤快的管理員，也只能在指定的預定時間內做數據備份。那么在備份完成后到災難發生之前的這段數據該如何保護呢?是不是就任由它丟失呢?顯然是不可能的。那答案是什么呢?就是日志文件。從前面對日志功能的描述中知道，任何對數據庫的更改都先寫入日志里，再由日志寫入數據庫，這樣我們只要找到日志文件，就可以重新進行模擬的操作來完成備份后的數據庫文件的更改了，舉個例子來看先：

　　假設我在凌晨3點完成了一次FULL BACKUP，備份完成后，系統正常運行，到下午4點的時候，系統突然崩潰。我用凌晨3點的數據恢復了數據庫，那么從凌晨3點到下午4點這段時間的數據哪里去找呢?這個時候就只能依賴于日志了。當完成數據庫恢復后，系統會自動的跟蹤到關聯的日志文件，如果發現有比當前數據庫還新的日志存在，系統就會自動的按照日志的順序將更改寫回到數據庫中去。因此這樣一來，從凌晨3點到下午4點的數據變更就被完整的恢復了。這就是日志的第二個作用：保證系統備份和恢復的完整性。當然前提是沒有使用循環日志!

　　看到了吧，啟用循環日志的危害是多么的大啊?備份是多么的重要啊?...如果你看到這里還執迷不悟啟用循環日志的話，寡人可就要罵你#%@￥*#%!@)$%^&*(%…

　　說到這里，有人可能要問，如果數據庫和日志同時損壞，如何辦?答案是：你趕緊去買體育彩票吧，呵呵!我在這里也只能說“盡量避免這樣的情況發生”。首先日志文件損壞的幾率要遠遠低于數據庫;第二，微軟建議將數據庫和日志分別存儲在不同的磁盤上;第三，我是絕對相信你的Exchange服務器用了RAID的!要是這樣還會同時壞，那就去買體育彩票吧，呵呵...對于管理員對日志文件的抱怨，合理的解決方法是定期做備份，雖然麻煩，但是公司付薪水給你就是讓你做這個事情的。寡人再強調一次：啟用循環日志是冒險的做法，當啟用循環日志后，一旦系統或者數據庫發生災難，想要恢復時，你就抱頭后悔或者跺腳吧!磁盤和數據誰更重要，相信你這位做系統管理的，應該很清楚的。