Log文件的作用 我們討論Exchange Server的郵件存儲，就不得不談談它的日志文件。我不止一次的聽到Exchange Server的管理員抱怨：日至文件每天都在瘋長，太消耗硬盤空間了。 我們來看看這些日志文件到底有些什么作用。對于每一個Storage Group，Exchange Server會產生一系列與之對應的日志文件。這些日志文件的大小為5M，擴展名為log，他們的前綴為E0x,其中x是日志文件所對應的Storage Group的編號[腳注:雖然在Storage Group的屬性中有“Log File Prefix”這一個文本框，但實際上這是不能更改的。]。因此第一個Storage Group的日志文件前綴為E00，第二個的為E01，依次類推。這樣做的目的是當存在多個Storage Group時，可以避免管理員在維護的時候把日志文件”張冠李戴”。另外，除了連續的Log文件，我們還能看到E0x.chk、Res1.log、 Res2.log等文件。 很多管理員都對日志文件非常的頭疼，那么，微軟在Exchange Server的數據庫系統中引入Log文件的目的是什么呢？我們從以下幾個方面來看： 1.作為一個企業級的郵件數據庫系統，必須做到數據安全和完整性的萬無一失。必須能夠面對隨時可能發生的崩潰和宕機，What happens if we crash? 要能夠把數據的損失減少到最新程度。 2.必須提供高性能的郵件吞吐能力，對數據庫中的郵件的事務操做在完成后必須馬上被記錄到存儲介質上（事務的持久性）。 3.當災難發生時，使用數據庫的備份恢復必須要返回到災難發生前一刻的數據庫狀態。 現在我們更進一步的來看一下，當我要修改郵箱中的內容時，被修改的內容首先被讀取出來放到內存中。實際的修改發生在內存中，當修改完成后，這些內容必須被寫回存儲介質，才能表示一個修改成功地完成了。 對于這樣的修改過程，在數據庫級別上，我們叫做一個“事務”。我們知道，為了確保數據庫的完整性和一致性，事務的操作是“原子級別”的。如果一個事務成功，那么標志著他所作的改變被永久的保存下來了；如果一個事務失敗，系統必須回到事務開始之前的狀態。 當系統在內存中完成修改時，事務并沒有完成。如果這個時候宕機，數據庫中保存的仍然是沒有更改的內容。那么，怎么樣確保在內存中完成的修改能夠在第一時間寫入到數據庫呢（以達到數據庫事務持久性的要求）？注意，這里的要是第一時間，也就是越快越好。如果我們直接向edb文件寫入，無法做到最快，因為，edb 文件通常都很大，I/O系統在對大的文件進行隨機寫入操作時，會花費大量的時間在等待磁盤查找到合適的磁道和扇區，當系統繁忙時，這將會是一個瓶頸。因此，數據庫系統使用日志文件，當內存中的更改完成后，首先寫入到日志文件中。日志文件的尺寸很小，寫入性能要遠遠優于龐大的edb文件。在寫入完成后，事務也隨之成功的保存在存儲介質上了。Exchange Server 的數據庫引擎會在后臺把Log文件中的內容寫入到數據庫中，因為此時事務操作已經完成，即使此時掉電或者宕機，也不會使完成的事務遺失。這是日志文件的第一個作用：確保事務能夠在第一時間保存到非易失存儲介質上。（提供持久性Durable支持） 根據上面的描述，我們知道在運行中的Exchange Server數據庫，是由三部分組成的 －－內存中已經完成修改但是還沒有寫入日志文件的內容（Dirt Page）。 －－還沒有寫入到數據庫文件的日志文件內容。 －－Edb和stm文件。 對于內存中的數據（Dirt Page），這些數據會在系統掉電或者崩潰時遺失。 Exchange Server使用了一個名為E0x.chk（Check Point）的文件記錄了那些Log文件已經寫入到了數據庫文件。這是一個類似指針的記錄。

我們可以使用命令 ESEUTIL /MK來查看這個文件chk的內容

C:/.../Exchsrvr/BIN> ESEUtil /mk “C:/.../Exchsrvr/mdbdata/e00.chk” Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode... Checkpoint file: C:/program files/exchsrvr/mdbdata/e00.chk LastFullBackupCheckpoint: (0x0,0,0) Checkpoint: (0x8,26DA,30) FullBackup: (0x0,0,0) FullBackup time: 00/00/1900 00:00:00 IncBackup: (0x0,0,0) IncBackup time: 00/00/1900 00:00:00 Signature: Create time:03/28/2004 20:26:10 Rand:6519986 Computer: Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers) ( off, 202, 10100, 1365, 10100, 128, 10240, 40828) Operation completed successfully in 1.47 seconds.

在命令的輸出中， Checkpoint: <0x8,26DA,30>表示了當前提交到數據庫文件的Log完全位置。其中，0x8是Log文件的序號，一般對應于E0x00008.log,剩下的兩個參數是Log文件內部頁面（page）的編號。 下面我們再看一下日志文件對系統備份和恢復的作用。 前面提到過，Exchange Server要求在災難發生后能夠恢復到災難發生前一刻的狀態。對于一般的系統，我們總是每周或者每天進行備份，那么，在備份之后和災難發生之前這段時間的數據如何保護？答案是日志文件。我們知道，對于數據庫的任何更改，都會先被寫入到日志文件，然后再由日志文件更新到數據庫中。我們現在假設有這樣一套系統，在每天的3:00 AM進行備份，備份完成后，系統正常運轉。如果在中午12:00的時候系統出現故障，管理員用3:00AM的磁帶恢復了系統，那么，從3:00AM到 12:00AM這段時間的數據，將由log文件來填補的。具體的情況是，當3:00AM的備份恢復完成后，Exchange Server會自動掃描到跟這個store相關聯的日志文件夾，如果發現有比當前數據庫還新的日志存在，Exchange Server會自動把這些日志按照順序寫入到數據庫中。因此，從3:00AM到12:00AM這段時間對數據庫所作的更改，可以被恢復回來。這是日志文件第二個重要的作用。（前提是沒有開啟循環日志功能） 有人可能會問，如果數據庫文件和日志文件同時損壞怎么辦？答案是這樣的：避免這種情況發生。首先，數據庫文件損壞的概率要遠遠大于日志文件，另外，微軟推薦的做法是把數據庫文件和日志文件分別放置在不同的磁盤上。我們會在下一期的文章中著重討論這個問題。 管理員針對日志文件的抱怨是，這些文件會每天不斷的增長，大量消耗硬盤空間。對于這個問題，唯一合理的解決辦法是：定期的做針對Storage Group的全備份或增量備份。因為Exchange Server會在全備份或增量備份完成后把這次備份之前產生的Log文件全部刪除。很多管理員手動的刪除日志文件，或者啟動“循環日志”來減少對硬盤空間的消耗，這都是不正確的做法。殘缺不全的日志文件會使系統在進行備份恢復的時候無法還原到最近的狀態。如果你的系統是一周做一次全備份，而你碰巧又在備份后刪除了一些日志文件，那么你就有可能在需要恢復的時候丟失備份以后的數據。記住，數據總是比磁盤空間更寶貴。 ESE數據庫引擎以及Information Store服務的啟動和關閉 在ESE 引擎加載數據庫文件時，它會檢查數據庫文件的一個特殊標志位。這個標志位保存了數據庫文件上次是否被正常關閉。這個狀態由“ Consistent”或“ Inconsistent”來表示。對于一個正常關閉的數據庫文件，所有在Log文件和內存中的內容都應該已經提交到數據庫文件中，只有在這個時候，數據庫才會被標記為“ Consistent”。有一點需要注意，在運行中的數據庫，它的狀態一定是“ Inconsistent”，因為在Log文件中肯定還有沒提交到數據庫文件內容。對于一個已經關閉并且狀態被標示為“ Inconsistent”的數據庫，并不意味著這個數據庫庫文件損壞了，“ Inconsistent”只是表示，還有未曾寫入到數據庫文件的內容保存在Log文件中。 使用命令 ESEUTIL /MH可以查常看數據庫的關閉狀態。

C:/.../Exchsrvr/BIN> ESEUtil /mh “C:/.../Exchsrvr/mdbdata/priv1.edb” Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode... Database: C:/program files/exchsrvr/mdbdata/priv1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,9 Engine ulVersion: 0x620,9 Created ulVersion: 0x620,9 DB Signature: Create time:03/28/2004 20:26:24 Rand:6536656 Computer: cbDbPage: 4096 dbtime: 63139 (0-63139) State: Clean Shutdown <-----表示數據庫關閉時的狀態 Log Required: 0-0 Streaming File: Yes Shadowed: Yes Last Objid: 574 …<略> … Operation completed successfully in 1.391 seconds.

State字段的“Clean Shutdown”表示數據庫處在Consistent狀態。 當ESE 加載數據庫文件時，對于“Consistent”的數據庫文件，它直接Mount其中的Store；對于“In consistent”的數據庫文件，ESE將執行稱之為“Soft Recovery”的過程，在這個過程中，未及時提交進數據庫文件的日志內容將被寫入數據庫。當所有的日志都寫入完畢，數據庫才會被標記為“ Consistent”狀態，然后正常加載。 Soft Recovery開始的時候，ESE會根據check point文件所指向的位置來進行Log文件的寫入(如果check point文件也損壞或者不存在，那么數據庫就從最舊的Log文件開始)。當ESE從Log文件向Store寫入數據時，它會根據dbTime這個時間戳來決定是否需要把Log文件寫入到數據庫。

原文出處 http://bbs.5dmail.net (中文名稱:5Dmail郵件資訊網)

淺談Exchange Server郵件存儲系統-原理篇(2)