本文從數據庫基本原理的角度入手通過對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的數據庫(ntdsdit文件)Windows DHCPWindows WINSSRS等後台都是由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 中IS服務對應的進程是storeexe每一個Storage Group會在storeexe進程中產生一個ESE引擎的實例
Exchange Server / 存儲系統的新特點
在微軟發布Exchange Server 時Exchange Server的存儲系統得到了很大的更新和改進
從ESE引擎的角度來看ESE的版本由中的ESE升級為ESE並且在如下方面得到了改進
I/O性能得到進一步的優化和提高
對日志文件增加了計算校驗和的操作進一步降低了數據庫出錯的可能性
提高了ESEUtil等維護工具的速度
相比幕後的ESE引擎Information Store方面的更新更加引人注意例如
在每台Server上提供多個Storage Group和Store的支持這是區別於的最大特征之一
數據庫中stm流文件格式的引入提高了操作Internet郵件的性能
Web Storage System的引入用戶可以使用多種協議訪問數據庫
EDB文件和STM文件的關系
在Exchange Server 中數據庫只有擴展名為edb的文件在Exchange Server 發布的時候微軟的重點還是企業內部的郵件傳輸系統當時主推的協議是MAPI協議這是微軟的私有郵件協議edb格式的數據庫為此協議作了專門的優化因此Exchange Server 為了支持Internet標准的SMTP郵件格式必須在每次處理Internet郵件時將其轉化為edb可以識別的格式這樣做帶來的巨大的性能損失
在Exchange Server 中微軟加大了對Internet標准協議SMTP的支持力度因此適用於Internet格式郵件的存儲就應運而生這就是stm文件
MAPI格式的郵件是基於微軟的RPC和二進制標准的而Internet格式的郵件是由純文本的郵件頭和經過MIME編碼的字符流組成的這兩者的特性就決定他們無法共存在一種數據庫結構的文件中
因此在Exchange Server 中微軟分別使用edb文件和stm文件保存這兩種格式的郵件並在edb和stm文件之間建立了關聯和引用對於用戶來說他的郵箱內容實際上是由跨越了edb和stm文件中的內容共同組成的值得一提的是edb文件中除了實際的信件信息以外還保存了每個用戶的郵箱結構每一個文件夾的內容列表和視圖等信息這是區別於stm中只保存字符流的地方
我們分下面幾種情況討論edb和stm文件的使用
用戶使用Outlook 以MAPI協議的方式和發送和訪問郵件
用戶使用 SMTP/POP等Internet協議訪問Exchange Server
情景一
當郵件從MAPI協議的客戶端(通常是Microsoft Office中的Outlook)提交到數據庫後郵件內容被保存在edb文件中
當用戶通過MAPI協議的客戶端對郵箱中的郵件進行讀取訪問時如果請求的郵件是保存在edb文件中的那麼信件被直接打開後返回給用戶如果被請求的信件保存在stm文件中(此信件是SMTP格式的)那麼Exchange Server數據庫引擎首先會做一個轉換把stm文件中的數據格式轉換成MAPI可以識別的格式然後再發送給客戶端這個過程稱之為On demand Conversion
情景二
用戶使用SMTP/POP客戶端(如Outlook Express FoxMail等)跟郵箱連接當SMTP協議向Exchange Server提交郵件時郵件的內容被保存在stm文件中前面提到過edb文件中包含了用戶郵箱的文件夾和信件內容列表因此當郵件被保存到stm 文件後數據庫引擎把這封郵件的一些重要信息(通常是郵件頭中的內容和信件在stm文件中的位置)提取出來保存到edb文件這個過程稱之為 Property Promotion正是有了這個過程用戶才可以得到信箱內容的完整列表MAPI客戶端需要訪問位於stm文件中的郵件時由此能夠得到stm文件中信件的正確保存位置當用戶使用POP協議來讀取郵件時如果被訪問的郵件位於edb文件中同樣一個從MAPI到Internet格式的轉化( Ondemand Conversion)也會在後台悄悄的發生
通過上面的描述我們知道在實際的Exchange Server環境中這兩個文件是緊密關聯的在任何時候都不要單獨的操作這兩個文件要始終把他們視為一個整體edb文件中包含了每一個郵箱的內容列表(store tables)當客戶端需要得到文件夾的內容時都必須向edb文件發出請求兩種格式的文件對兩種類型的協議分別提供了支持有效的減少了不必要的格式轉換的發生
Log文件的作用
我們討論Exchange Server的郵件存儲就不得不談談它的日志文件我不止一次的聽到Exchange Server的管理員抱怨日至文件每天都在瘋長太消耗硬盤空間了
我們來看看這些日志文件到底有些什麼作用對於每一個Storage GroupExchange Server會產生一系列與之對應的日志文件這些日志文件的大小為M擴展名為log他們的前綴為Ex其中x是日志文件所對應的Storage Group的編號[腳注:雖然在Storage Group的屬性中有Log File Prefix這一個文本框但實際上這是不能更改的]因此第一個Storage Group的日志文件前綴為E第二個的為E依次類推這樣做的目的是當存在多個Storage Group時可以避免管理員在維護的時候把日志文件張冠李戴另外除了連續的Log文件我們還能看到ExchkReslog Reslog等文件
很多管理員都對日志文件非常的頭疼那麼微軟在Exchange Server的數據庫系統中引入Log文件的目的是什麼呢?我們從以下幾個方面來看
作為一個企業級的郵件數據庫系統必須做到數據安全和完整性的萬無一失必須能夠面對隨時可能發生的崩潰和宕機What happens if we crash? 要能夠把數據的損失減少到最新程度
必須提供高性能的郵件吞吐能力對數據庫中的郵件的事務操做在完成後必須馬上被記錄到存儲介質上(事務的持久性)
當災難發生時使用數據庫的備份恢復必須要返回到災難發生前一刻的數據庫狀態
現在我們更進一步的來看一下當我要修改郵箱中的內容時被修改的內容首先被讀取出來放到內存中實際的修改發生在內存中當修改完成後這些內容必須被寫回存儲介質才能表示一個修改成功地完成了
對於這樣的修改過程在數據庫級別上我們叫做一個事務我們知道為了確保數據庫的完整性和一致性事務的操作是原子級別的如果一個事務成功那麼標志著他所作的改變被永久的保存下來了;如果一個事務失敗系統必須回到事務開始之前的狀態
當系統在內存中完成修改時事務並沒有完成如果這個時候宕機數據庫中保存的仍然是沒有更改的內容那麼怎麼樣確保在內存中完成的修改能夠在第一時間寫入到數據庫呢(以達到數據庫事務持久性的要求)?注意這裡的要是第一時間也就是越快越好如果我們直接向edb文件寫入無法做到最快因為edb 文件通常都很大I/O系統在對大的文件進行隨機寫入操作時會花費大量的時間在等待磁盤查找到合適的磁道和扇區當系統繁忙時這將會是一個瓶頸因此數據庫系統使用日志文件當內存中的更改完成後首先寫入到日志文件中日志文件的尺寸很小寫入性能要遠遠優於龐大的edb文件在寫入完成後事務也隨之成功的保存在存儲介質上了Exchange Server 的數據庫引擎會在後台把Log文件中的內容寫入到數據庫中因為此時事務操作已經完成即使此時掉電或者宕機也不會使完成的事務遺失這是日志文件的第一個作用確保事務能夠在第一時間保存到非易失存儲介質上(提供持久性Durable支持)
根據上面的描述我們知道在運行中的Exchange Server數據庫是由三部分組成的
內存中已經完成修改但是還沒有寫入日志文件的內容(Dirt Page)
還沒有寫入到數據庫文件的日志文件內容
Edb和stm文件
對於內存中的數據(Dirt Page)這些數據會在系統掉電或者崩潰時遺失
Exchange Server使用了一個名為Exchk(Check Point)的文件記錄了那些Log文件已經寫入到了數據庫文件這是一個類似指針的記錄
我們可以使用命令 ESEUTIL /MK來查看這個文件chk的內容
C:\\Exchsrvr\BIN> ESEUtil /mk C:\\Exchsrvr\mdbdata\echk
Microsoft(R) Exchange Server(TM) Database Utilities
Version Copyright (C) Microsoft Corporation All Rights Reserved
Initiating FILE DUMP mode
Checkpoint file: C:\program files\exchsrvr\mdbdata\echk
LastFullBackupCheckpoint: (x)
Checkpoint: (xDA)
FullBackup: (x)
FullBackup time: // ::
IncBackup: (x)
IncBackup time: // ::
Signature: Create time:// :: Rand: Computer:
Env (CircLogSessionOpentblVerPageCursorsLogBufsLogFileBuffers)
( off )
Operation completed successfully in seconds
在命令的輸出中 Checkpoint: <xDA>表示了當前提交到數據庫文件的Log完全位置其中x是Log文件的序號一般對應於Exlog剩下的兩個參數是Log文件內部頁面(page)的編號
下面我們再看一下日志文件對系統備份和恢復的作用
前面提到過Exchange Server要求在災難發生後能夠恢復到災難發生前一刻的狀態對於一般的系統我們總是每周或者每天進行備份那麼在備份之後和災難發生之前這段時間的數據如何保護?答案是日志文件我們知道對於數據庫的任何更改都會先被寫入到日志文件然後再由日志文件更新到數據庫中我們現在假設有這樣一套系統在每天的: AM進行備份備份完成後系統正常運轉如果在中午:的時候系統出現故障管理員用:AM的磁帶恢復了系統那麼從:AM到 :AM這段時間的數據將由log文件來填補的具體的情況是當:AM的備份恢復完成後Exchange Server會自動掃描到跟這個store相關聯的日志文件夾如果發現有比當前數據庫還新的日志存在Exchange Server會自動把這些日志按照順序寫入到數據庫中因此從:AM到:AM這段時間對數據庫所作的更改可以被恢復回來這是日志文件第二個重要的作用(前提是沒有開啟循環日志功能)
有人可能會問如果數據庫文件和日志文件同時損壞怎麼辦?答案是這樣的避免這種情況發生首先數據庫文件損壞的概率要遠遠大於日志文件另外微軟推薦的做法是把數據庫文件和日志文件分別放置在不同的磁盤上我們會在下一期的文章中著重討論這個問題
管理員針對日志文件的抱怨是這些文件會每天不斷的增長大量消耗硬盤空間對於這個問題唯一合理的解決辦法是定期的做針對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\privedb
Microsoft(R) Exchange Server(TM) Database Utilities Version
Copyright (C) Microsoft Corporation All Rights Reserved
Initiating FILE DUMP mode
Database: C:\program files\exchsrvr\mdbdata\privedb
File Type: Database
Format ulMagic: xabcdef
Engine ulMagic: xabcdef
Format ulVersion: x
Engine ulVersion: x
Created ulVersion: x
DB Signature: Create time:// :: Rand: Computer:
cbDbPage:
dbtime: ()
State: Clean Shutdown <表示數據庫關閉時的狀態
Log Required:
Streaming File: Yes
Shadowed: Yes
Last Objid:
…<略> …
Operation completed successfully in 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: ESE
Event Category: Logging and Recovery
Event ID:
Date: //
Time: :: AM
User: N/A
Computer:
Description: Information Store (XXXX) The database engine has begun replaying logfile \\Elog
我們也可以針對已經Dismount的並且是處在Inconsistent的數據庫手工地進行Soft Recovery
具體的命令是eseutil /r後跟數據庫文件的路徑(推薦在掉電重啟以後執行此命令可以先運行eseutil /mh確定數據庫狀態如果是Inconsistent再執行此命令)
由此我們可以發現Exchange Server有能力對未正常關閉的數據庫進行自我修復因此ESE確保了即使在突然掉電的情況下數據庫仍然能夠處在一個可恢復的狀態並且會在重啟服務以後自動完成狀態檢測和恢復
M盤的來龍去脈
在Exchange Server 發布時微軟提出了Web Storage System的概念其核心就是提供多種途徑來訪問Exchange Server的數據庫這些途徑包括
文件系統/IFS
Http WebDAV
ExOLEDB/ ADO
CDO
其中提供文件系統服務的IFS技術是引起爭議比較多的一個模塊在安裝Exchange Server 後系統會出現一個M盤這個M盤就是由微軟通過IFS(Installable File System)技術實現的一個數據庫到文件系統的映射開發人員可以通過標准的文件操作API(如CreateFile OpenFile等)來訪問Exchange Server的郵箱和郵件
打開M盤你可以看到一個以你當前域名命名的文件夾在這個文件加下面你會看到一個包含了所有郵箱的文件夾名為MBXMBX下面是以用戶的姓名來命名的郵箱文件夾在每個文件夾下面都可以看到Inbox Outbox等郵箱的內容每一封信件都是以擴展名為EML的文件來表示的
ExIFS使用了一個名為\\\BackOfficeStorage的特殊共享名稱來指向數據庫文件你可以在命令行中運行Dir \\\BackOfficeStorage\n\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內核模式的ExIFSsys驅動程序來實現的
我們知道文件系統和Exchange Server的store是兩個完全不同的體系結構文件系統中的文件只包含比較少的屬性而保存在Store中的郵件有其特定的屬性並且在 Store中郵件之間還有非常復雜的關聯關系(跟郵箱的關系郵箱文件夾的視圖等)因此M中以EML形式存在的文件(郵件)只是反映了郵件所有屬性和關系的一個子集一些對於M盤的不適當操作往往會破壞數據庫內部的關系造成數據庫損壞比較典型的例子是防病毒軟件掃描M盤發現嫌疑病毒 並予以清除根據微軟技術支持部門的統計這是造成Exchange Server Store數據庫損壞的主要原因之一因為防病毒軟件在清除病毒文件(EML文件)時采取野蠻施工手段往往會破壞數據庫內部的關聯和郵件結構進而造成數據庫文件內部結構的損壞
另一個針對ExIFS的錯誤觀點是管理員認為對M進行備份即可保存Exchange Server的狀態和所有數據這是完全不正確的M盤只是數據庫內容在文件系統上的一個映射M中所保存的文件歸根結底還是數據庫中保存的郵件由於映射到M盤數據庫中的郵件關聯和關系都被去掉了備份M盤是沒有辦法恢復數據庫的所有信息
From:http://tw.wingwit.com/Article/os/fwq/201311/10202.html
