本文以數據庫的基本原理為基礎
分析了EXCHANGE SERVER的存儲系統
並說明了各部分的作用
一IIS服務和ESE的層次關系 IIS服務是EXCHANGE服務器中重要的服務之一
它控制著對郵箱和PF的存儲操作請求
EXCHANGE服務器的存儲實際上是由ESE的數據庫引擎來管理的
這個ESE引擎是微軟專門為保存非關系型數據而開發的
目前在微軟的很多產品中都有廣泛的應用
如
AD數據庫
DHCP
WINS
SRS等等
EXCHANGE的數據庫是由EDB文件
STM文件和LOG文件組成
在這些文件裡
微軟使用了
B+樹
的內部數據結構
ESE的引擎的任務之一
就是當IIS服務請求訪問數據庫的時候
把這些請求轉化為對內部數據結構的讀寫訪問
B+樹的特點是能夠對存儲在硬盤上的數據提供快速訪問能力
微軟利用
B+樹
作為ESE的後台結構的主要原因
就是盡可能的提高訪問數據時I/O性能
當然
這些結構對於EXCHANGE STORE來說是透明的
另外
作為一個數據庫系統
ESE有責任提供事務級別的操作的支持
並維護數據庫的完整性和一致性
對數據庫系統而言
我們提到事務時
一般用ACID來描述事務的特點
A
Atomic（原子的）
事務必須是全或全無的操作
要麼全部成功更新
要麼全部不被更新
C
Consistent（一致的）
一個成功提交的事務必須使數據庫處於一個一致的狀態
I
Isolated（孤立的）
所有未提交的更改都必須能夠和其他事務孤立
D
Durable（持久的）
當事務一旦提交
所做的更改必須存儲到穩定的介質上
防止系統失敗導致的數據庫不一致
（此點非常重要！！）
二EXCHANGE /存儲系統的新特點 在EX
中
ESE的版本為ESE
而在EX
/
裡
ESE版本已經升級ESE
了
ESE引起在以下方面得到了改進
* I/O性能進一步提高和優化
* 對日志文件增加了計算校驗操作
* 提高了ESEUTIL等工具的維護速度
而IIS也在以下方面有了更新
* 在每個SERVER上提供多個SG支持
* 數據庫STM文件格式的引入
提高了INTERNET郵件的性能
* WSS的引入
用戶可以使用多種協議訪問數據庫
三EDB和STM的關系 常有人問
EDB文件是數據庫
那STM文件是做什麼用的？可以刪除嗎？
在EX
裡
只有EDB文件
因為在EX
發布時
微軟主推的是內部郵件系統
因此其主要協議為MAPI
這是微軟的私有郵件西醫
EDB文件是專門為此協議優化過的
因此在EX
中
為了支持INTERNET郵件
必須在每次處理INTERNET郵件時
做一個格式轉換
這顯然帶來了性能的損失
在EX
裡
微軟加大了對INTERNET郵件的支持
這就是STM文件的來源
MAPI格式是RPC和二進制標准的
而STM是純文本加上一些MIME編碼格式
這樣的區別使得它們不可能存儲在同一數據庫裡
因此EX
中
微軟開始使用EDB和STM兩個文件來分別保存兩種格式的郵件
並且在兩個文件之間建立了引用和關聯
對於用戶來說
它的郵箱實際上是跨越了EDB和STM文件共同組成的
另外
需要注意的是
EDB文件中還保留著用戶的郵箱結構
所以EDB文件更加重要
那麼EDB和STM是怎麼協同工作的呢？我們以幾個情景來分析之
情景一
用戶使用OUTLOOK（MAPI）發送接收郵件
在該情景下
用戶將郵件通過MAPI協議提交給數據庫
直接被保存EDB文件中
當用戶通過MAPI訪問郵箱裡的郵件時
如果被訪問的郵件在EDB裡
直接返回
如果在STM裡（如外來郵件）
則執行轉換
將STM轉換為EDB文件格式
再返回用戶
情景二
用戶使用標准SMTP/POP
/IMAP
等協議訪問
用戶使用非MAPI協議提交的郵件
內容保存在STM文件裡
但是由於EDB裡有郵箱結構
STM沒有
因此系統會把郵件的重要信息提取出來
放在EDB裡
當用戶用MAPI提取郵件時
過程同上
當用戶通過標准協議訪問時
同樣需要進行格式轉換
轉換為STM文件格式返回
這些轉換是在後台發生的
對用戶來說是透明的
通過上面的描述
你會看到
這兩個文件是緊密聯系的缺一不可
所以
在任何時間我們都不要單獨操作這兩個文件
它們是一個整體
同時也要注意的是
無論用戶使用何方式訪問郵箱
都需要向EDB文件請求郵箱結構信息
這是需要注意的
四LOG文件的重大作用 在論壇裡經常會看到有人說我的硬盤怎麼很快就沒了
一看原來是日志文件搞的鬼
於是就有人刪除日志文件
甚至使用循環日志來強制減少日志
甚至有人提出這樣的疑問
日志到底有什麼用？是不是多余的？那我們來看看日志的重大作用
對於一個SG來說
系統會產生一系列的日志
這些日志的擴展名為LOG
前綴一般是E
E
……除了這些連續的日志文件外
還有一些特殊的日志文件（res
log
res
log
e
x
chk）））
它們又有什麼用呢？我們的管理員通常不喜歡備份這一操作
因此對這些日志是痛恨不已啊
那麼微軟在EXCHANGE數據庫系統中引入日志的作用難道真的是多此一舉嗎？我們從以下幾個方面來考察一下日志的作用
作為一個企業級的郵件系統
必須要保證數據安全和完整
必須能夠面對隨時可能發生的意外災難
把數據損失降低到最小
必須提供高性能的郵件處理能力
對數據庫中的郵件的事務操作在完成後必須馬上（或是說立即）被記錄在存儲介質上（見前面的事務持久性說明）
災難發生後
使用數據庫備份恢復必須要返回到災難發生前一刻的數據庫狀態（這是至關重要的！！）
現在我們來更進一步的看一下
當用戶要修改郵箱中的內容時
被修改的內容首先被提取出來放到內存中
實際的修改是發生在內存裡的
這是眾所周知的
當修改完成後
這些內容必須被盡快寫回存儲介質
這樣才表示一個事務成功完成了
從事務的描述中我們可以看到
事務是具有原子特性的
為了保證數據庫的一致和完整
事務必須全部成功或全部失敗
如果事務失敗
則必須回滾到事務開始的狀態
而當郵件在內存中修改完成後
此時事務並沒有完成（為什麼呢？）因為一旦系統崩潰
這些修改就丟失了
所以要確保事務修改完成
必須盡快將修改寫回到數據庫裡去（也就是硬盤上）
這也是事務的持久性要求
注意
我們這裡說的第一時間或是盡快
是一個什麼樣的概念
如果我們直接修改EDB文件
由於EDB文件比較大
那麼在硬盤上修改一個大文件
就 需要花費大量的時間在等待和尋找數據存儲塊上（見操作系統原理）
當系統出現高負載的繁忙狀態時
這將是一個非常大的瓶頸
也就無法做到
盡快
了
那怎麼辦呢？所以數據庫系統使用了日志
而日志通常很小（EXCHANGE的日志只有
MB）
向這些文件寫入修改結果是很快速的
因此當內存的修改完成後
這些結果就會立即寫入日志中
以保證了事務的持久性
當成功寫入日志後
該事務就成功完成了（現在在硬盤上了
不會因為當機丟失了）接下來
ESE引擎會在後台慢慢將這些日志裡的修改記錄寫回真正的數據庫裡去（這對用戶來說已經不是那麼重要了）
這就是日志的第一個作用
確保事務在第一時間（盡可能快的）保存到非易失存儲器上（提供了事務持久性支持）
根據上面的藐視
我們看到運行中的EXCHANGE數據庫
是由三個部分組成的
* 內存中已經完成處理還沒有寫會到日志裡的內容（Dirt page）
* 還沒有寫到數據庫文件裡的日志內容
* EDB和STM數據庫文件
對於第一個部分
一旦掉電就回丟失的
是最不安全的
而對於第二部分的內容
系統通過檢查點文件（CHK）來標記哪些日志已經被寫入數據庫了
而哪些還沒有
CHK文件類似一個指針
我們可以用
ESEUTIL /MK
來檢查CHK文件裡的內容
在該命令的輸出中的checkpoint:<0x8,26d1,29>這樣的東西就是檢查點位置
它表示E
x
的日志的頁面序號已經被成功寫入數據庫了
大家可以自己看看
）
前面提到過
EXCHANGE系統在出現災難時
應能恢復到災難發生前的時刻的狀態
這是非常重要的
但即使是最勤快的管理員
也只能在指定的預定時間內做系統備份
而不可能時時刻刻的都在備份
那麼在備份完成後到災難發生之前的這段數據該如何保護呢？是不是就任由它丟失呢？顯然是不可能的
那答案是什麼呢？就是日志文件
前面我們知道
任何對數據庫的更改都先寫入日志裡
再由日志寫入數據庫
這樣我們只要找到日志文件
就可以重新進行模擬的操作來完成備份後的數據庫文件的更改了
我們舉個例子來看看
假設我們在凌晨
點完成了一次FULLBACKUP
備份完成後
系統正常運行
到下午
點的時候
系統突然崩潰
管理員用凌晨
點的數據恢復了數據庫
那麼從凌晨
點到下午
點這段時間的數據變更
就只能依賴於日志了
當完成數據庫恢復後
系統會自動的跟蹤到關聯的日志文件
如果發現有比當前數據庫還新的日志存在
系統就會自動的按照日志的順序將更改寫回到數據庫中去
因此這樣一來
從凌晨
點到下午
點的數據變更就被完整的恢復了
這就是日志的第二個作用
保證系統備份和恢復的完整性
當然前提是沒有使用循環日志！！（看到了吧
使用循環日志的危害是相當大的
比起你的數據來說
多做幾次備份不是沒有意義的吧？
說到這裡
有人可能要問
如果數據庫和日志同時損壞
如何辦？答案是
盡量避免這樣的情況發生
首先數據庫損壞的幾率要大於日志
另外
微軟建議將數據庫和日志分別存儲在不同的磁盤上
要是這樣還會同時壞
那就沒有辦法了
呵呵
對於管理員對日志文件的抱怨
合理的解決方法是定期做備份
啟用循環日志是不正確的做法
當啟用循環日志後
一旦系
From:http://tw.wingwit.com/Article/os/fwq/201311/29784.html
