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

本文從數據庫基本原理的角度入手，通過對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文件發出請求。兩種格式的文件，對兩種類型的協議分別提供了支持，有效的減少了不必要的格式轉換的發生。