http://blog.csdn.net/starlee1738/archive/2005/01/22/264093.aspx
淺談Exchange Server郵件存儲系統-原理篇（轉）
本文從數據庫基本原理的角度入手，通過對Exchange Server Store模塊的分析，來揭示Exchange Server郵件存儲系統的工作原理和維護技巧。文章適合有一定Exchange Server管理經驗的專業IT人員閱讀，目的是使讀者在維護Exchange Server郵件系統時，能夠做到知其然，更知其所以然。
Information Store和Extensible Storage Engine的層次關係
衆所周知，在Exchange Server中，Information Store （簡稱IS）Service是至關重要的。這個服務控制了對郵箱和公共文件夾數據庫的操作請求。
更 進一步的來看，事實上Exchange Server的數據庫系統是由名爲Extensible Storage Engine（簡稱ESE）的數據庫引擎來管理的。這個ESE引擎是微軟專門爲保存非關係型數據而開發的，在微軟的很多系統中都有應用：例如，AD的數據 庫（ntds.dit文件）、Windows DHCP、Windows WINS、SRS等，後臺都是由ESE數據庫來提供支持的。
我們知道，Exchange Server的數據庫由edb文件、stm文件和衆多的log文件組成。在這些文件內部，微軟使用了名爲“B+樹”的內部數據結構，ESE引擎的任務之 一，就是當Information Store服務請求訪問數據庫的時候，把這些請求轉化成對內部數據結構的讀寫訪問。B+樹的特點是能夠對存儲在磁盤上的數據提供快速的訪問能力。微軟選用 B+樹作爲ESE後臺結構的一個原因，就是儘可能提高訪問數據時的I/O性能。這些B+樹的結構對於Exchange Server Store服務來說是透明的，Store只需要把請求發給ESE即可，ESE會對這些數據結構進行操作。
另外，作爲一個數據庫系 統，ESE有責任提供事務（Transaction）級別操作的支持，並維護整個數據庫的完整性和一致性。對於現代數據庫系統，當我們提到事務時，一般用 ACID這樣的縮寫來描述事務的特點：
我們會在後面的篇幅中詳細的討論Exchange Server和ESE是怎樣實現上述的要求的。
對於Information Store Service來說，ESE封裝了對數據庫操作的所有細節，IS只要根據ESE提供的接口進行調用既可。在Exchange Server 2000中，IS服務對應的進程是store.exe，每一個Storage Group會在store.exe進程中產生一個ESE引擎的實例。
Exchange Server 2000/2003 存儲系統的新特點
在微軟發佈Exchange Server 2000時，Exchange Server的存儲系統得到了很大的更新和改進。
從ESE引擎的角度來看，ESE的版本由5.5中的ESE97升級爲ESE98，並且在 如下方面得到了改進：
1.I/O性能得到進一步的優化和提高
2.對日誌文件增加了計算校驗和的操作，進一步降低了數據庫出錯的可 能性
3.提高了ESEUtil等維護工具的速度
相比幕後的ESE引擎，Information Store方面的更新更加引人注意，例如：
1.在每臺Server上提供多個Storage Group和Store的支持，這是區別於5.5的最大特徵之一
2.數據庫中stm流文件格式的引入，提高了操作Internet郵件的性能
3.Web Storage System的引入，用戶可以使用多種協議訪問數據庫
EDB文件和STM文件的關係
在Exchange Server 5.5中，數據庫只有擴展名爲edb的文件。在Exchange Server 5.5發佈的時候，微軟的重點還是企業內部的郵件傳輸系統，當時主推的協議是MAPI協議，這是微軟的私有郵件協議，edb格式的數據庫爲此協議作了專門 的優化。因此，Exchange Server 5.5爲了支持Internet標準的SMTP郵件格式，必須在每次處理Internet郵件時將其轉化爲edb可以識別的格式，這樣做帶來的巨大的性能 損失。
在Exchange Server 2000中，微軟加大了對Internet標準協議SMTP的支持力度。因此，適用於Internet格式郵件的存儲就應運而生：這就是stm文件。
MAPI 格式的郵件是基於微軟的RPC和二進制標準的，而Internet格式的郵件是由純文本的郵件頭和經過MIME編碼的字符流組成的。這兩者的特性就決定他 們無法共存在一種數據庫結構的文件中。
因此，在Exchange Server 2000中，微軟分別使用edb文件和stm文件保存這兩種格式的郵件，並在edb和stm文件之間建立了關聯和引用。對於用戶來說，他的郵箱內容實際上 是由跨越了edb和stm文件中的內容共同組成的。值得一提的是，edb文件中除了實際的信件信息以外，還保存了每個用戶的郵箱結構、每一個文件夾的內容 列表和視圖等信息。這是區別於stm中只保存字符流的地方。
我們分下面幾種情況討論edb和stm文件的使用：
1.用戶 使用Outlook 以MAPI協議的方式和發送和訪問郵件
2.用戶使用 SMTP/POP3等Internet協議訪問Exchange Server。
情景一：
當郵件從MAPI協議的客戶端(通常是Microsoft Office中的Outlook)提交到數據庫後，郵件內容被保存在edb文件中。
當用戶通過MAPI協議的客戶端對郵箱中的郵件進行讀 取訪問時，如果請求的郵件是保存在edb文件中的，那麼信件被直接打開後返回給用戶。如果被請求的信件保存在stm文件中（此信件是SMTP格式的），那 麼，Exchange Server數據庫引擎首先會做一個轉換，把stm文件中的數據格式轉換成MAPI可以識別的格式，然後再發送給客戶端。這個過程稱之爲“On- demand Conversion”。
情景二：
用戶使用SMTP/POP3客戶端（如Outlook Express, FoxMail等）跟郵箱連接。當SMTP協議向Exchange Server提交郵件時，郵件的內容被保存在stm文件中。前面提到過，edb文件中包含了用戶郵箱的文件夾和信件內容列表，因此，當郵件被保存到stm 文件後，數據庫引擎把這封郵件的一些重要信息（通常是郵件頭中的內容和信件在stm文件中的位置）提取出來，保存到edb文件，這個過程稱之爲 “Property Promotion”。正是有了這個過程，用戶纔可以得到信箱內容的完整列表，MAPI客戶端需要訪問位於stm文件中的郵件時，由此能夠得到stm文件 中信件的正確保存位置。當用戶使用POP3協議來讀取郵件時，如果被訪問的郵件位於edb文件中，同樣，一個從MAPI到Internet格式的轉化（“ On-demand Conversion”）也會在後臺悄悄的發生。
通過上面的描述，我們知道在實際的Exchange Server環境中，這兩個文件是緊密關聯的。在任何時候都不要單獨的操作這兩個文件，要始終把他們視爲一個整體。edb文件中包含了每一個郵箱的內容列 表（store tables），當客戶端需要得到文件夾的內容時，都必須向edb文件發出請求。兩種格式的文件，對兩種類型的協議分別提供了支持，有效的減少了不必要的 格式轉換的發生。
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文件寫入到數據庫。
在這個過程中，Event Log中會有如下的記錄
Event Type: Information Event Source: ESE98 Event Category: Logging and Recovery Event ID: 301 Date: 10/17/2001 Time: 5:52:11 AM User: N/A Computer: <server_name> Description: Information Store (XXXX) The database engine has begun replaying logfile ..\..\E0014553.log. |
我們也可以針 對已經“Dis-mount”的並且是處在“Inconsistent”的數據庫手工地進行“Soft Recovery”。
具體的命令 是“eseutil /r”，後跟數據庫文件的路徑。（推薦在掉電重啓以後執行此命令，可以先運行eseutil /mh確定數據庫狀態，如果是“Inconsistent”，再執行此命令）
由此我們可以發現，Exchange Server有能力對未正常關閉的數據庫進行“自我修復”。因此，ESE確保了即使在突然掉電的情況下，數據庫仍然能夠處在一個可恢復的狀態，並且會在重 啓服務以後自動完成狀態檢測和恢復。
M盤的來龍去脈
在Exchange Server 2000發佈時，微軟提出了“Web Storage System”的概念，其核心就是提供多種途徑來訪問Exchange Server的數據庫。這些途徑包括
文件系統/IFS
－－Http WebDAV
－－ExOLEDB/ ADO
－－CDO
其 中，提供文件系統服務的IFS技術是引起爭議比較多的一個模塊。在安裝Exchange Server 2000後，系統會出現一個M盤。這個M盤，就是由微軟通過IFS（Installable File System）技術實現的一個數據庫到文件系統的映射。開發人員可以通過標準的文件操作API（如CreateFile, OpenFile等）來訪問Exchange Server的郵箱和郵件。
打開M盤，你可以看到一個以你當前域名命名的文件夾。在這個文 件加下面，你會看到一個包含了所有郵箱的文件夾，名爲MBX。MBX下面，是以用戶的姓名來命名的郵箱文件夾，在每個文件夾下面，都可以看到Inbox、 Outbox等郵箱的內容。每一封信件，都是以擴展名爲EML的文件來表示的。
ExIFS使用了一個名爲\\. \BackOfficeStorage的特殊共享名稱來指向數據庫文件。你可以在命令行中運行“Dir \\.\BackOfficeStorage\domain.con\MBX”，這個命令的實行結果跟直接使用M盤作爲盤符是一樣的。
我 們可以通過修改註冊表的方式所來改變Exchange Server所映射的盤符。
HLKM\System\CurrentControlSet\Services\ExIFS\Parameters Name: DriveLetter Data Type: REG_SZ Value: Drive letter for IFS (盤符，不需要跟冒號) |
在 更改註冊表以後，需要重啓Information Store Service使更改生效。
我們也可以使用如下的命令行工具來改變M盤的 映射：
Subst X: \\.\BackOfficeStorage 註釋：把Exchange Store映射到X盤 Subst /d M: 註釋：刪除對M盤的映射 |
如果我們移除了M盤，我們還是可以通過\\. \BackOfficeStorage這個共享名字來訪問Exchange Server的數據庫。
ExIFS在Windows中是作爲 一個隱藏的服務來運行的。下面的註冊表鍵值定義了這個服務的參數：
| HLKM\System\CurrentControlSet\Services\ExIFS\Parameters |
由 於這是一個隱藏的服務，因此我們沒有辦法通過Service控制面板來對這個服務進行控制。但是我們可以通過命令行來做到：
NET Start ExIFS 註釋：啓動服務 NET Stop ExIFS 註釋：停止服務 |
下面這張圖表示了 ExIFS的架構。
ExIFS是使用運行在Windows內核模式的ExIFS.sys驅動程序來實現的。
我 們知道，文件系統和Exchange Server的store是兩個完全不同的體系結構。文件系統中的文件只包含比較少的屬性，而保存在Store中的郵件，有其特定的屬性，並且，在 Store中，郵件之間還有非常複雜的關聯關係（跟郵箱的關係，郵箱文件夾的視圖等）。因此，M中以EML形式存在的文件（郵件），只是反映了郵件所有屬 性和關係的一個子集。一些對於M盤的不適當操作，往往會破壞數據庫內部的關係，造成數據庫損壞。比較典型的例子是，防病毒軟件掃描M盤，發現“嫌疑病毒” 並予以清除。根據微軟技術支持部門的統計，這是造成Exchange Server Store數據庫損壞的主要原因之一。因爲防病毒軟件在清除病毒文件（EML文件）時，採取“野蠻施工”手段，往往會破壞數據庫內部的關聯和郵件結構，進 而造成數據庫文件內部結構的損壞。
另一個針對ExIFS的錯誤觀點是：管理員認爲對M進行備份即可保存Exchange Server的狀態和所有數據。這是完全不正確的。M盤只是數據庫內容在文件系統上的一個映射，M中所保存的“文件”，歸根結底還是數據庫中保存的郵件。 由於映射到M盤，數據庫中的郵件關聯和關係都被去掉了，備份M盤，是沒有辦法恢復數據庫的所有信息。