可延伸儲存引擎架構

適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上次修改主題的時間： 2008-11-19

Hub Transport Server 和 Edge Transport Server 上的 Exchange 信箱資料庫和佇列會利用可延伸儲存引擎 (ESE) 資料庫。ESE 是一種多重使用者的索引循序存取方法 (ISAM) 資料表管理員，其中含有完整的「資料操作語言 (DML)」及「資料定義語言 (DDL)」功能。ESE 允許應用程式儲存記錄並建立索引，以便以不同方式存取那些記錄。

ESE 有兩種版本：

• ESENTl   Active Directory 及許多 Microsoft Windows 元件的資料庫引擎。Active Directory 的 ESENT 實作使用 10 MB 的記錄檔和 8 KB 的分頁，而不像其他版本的 ESE (使用 5 MB 的記錄檔和 4 KB 的分頁大小)。
• ESE98   Exchange 2000 Server、Exchange Server 2003 及 Exchange Server 2007 中的資料庫引擎。
• ESE 先前稱為 Joint Engine Technology (JET) Blue。JET Blue 與 Microsoft Access 中的 JET 版本 (稱為 JET Red) 兩者是不同的。

交易

ESE 是精密的交易型資料庫引擎。交易是一系列的作業，它們以不可部分完成的單位來處理。交易中的所有作業會完成並永久儲存，或者是不執行任何作業。例如，請想想將郵件從收件匣移到刪除的郵件資料夾時所牽涉的作業。郵件會從一個資料夾刪除、新增到另一個資料夾，並且更新資料夾內容。如果發生失敗，您不會想要有兩份郵件、沒有任何一份郵件，或是資料夾內容值 (例如郵件數) 與實際資料夾內容不一致。

為了避免這樣的問題，ESE 會將作業包在「交易」裡。ESE 會確保在交易認可到資料庫檔案之前，不會永久地套用任何作業。當交易認可到資料庫檔案後，才會永久套用所有作業。

如果伺服器停止回應，ESE 也會在您重新啟動伺服器並復原任何未認可的交易時，處理自動復原。如果 ESE 在交易認可之前失敗，整個交易都會復原，彷彿交易不曾發生。如果 ESE 在交易認可之後停止回應，則整個交易會保留下來，而且用戶端可以看得到這些變更。

ACID 交易

前一節所列的那種交易通常稱為「ACID 交易」。ACID 是下列屬性的縮略字：

• Atomic (不可部分完成)   這個術語表示交易狀態變更為全有或全無。不可部分完成的狀態變更包括了資料庫變更，以及轉換器上的郵件與動作。
• Consistent (一致)   這個術語表示交易為正確的狀態轉換。此動作以群組方式發生，且不會違反任何一項與狀態相關的完整性限制。這需要交易是正確的程式。
• Isolated (隔離)  這個術語表示，即使交易同時執行，對每個交易 (t) 而言，其他交易都宛如在 t 之前或在 t 之後執行，但不會兩者同時成立。
• Durable (耐久)   即使系統停止回應，已認可的交易也會保留在資料庫中。

版本儲存區

版本儲存區讓 ESE 能夠追蹤並管理目前的交易。因此，ESE 可以通過 ACID 測試的「隔離」與「一致」部分。版本儲存區會維護對資料庫所作修改的記憶體內清單。

版本儲存區用於下列情況：

• 復原   如果某交易必須進行復原，它會檢查版本儲存區，以取得它所執行的作業清單。反向執行所有作業，交易即可復原。
• 寫入衝突偵測   如果兩個不同的工作階段嘗試修改相同的記錄，版本儲存區會通知並拒絕第二項修改。
• 可重複讀取   當工作階段開始某個交易時，遇到的資料庫檢視始終會是相同的，即使其他工作階段修改其正在檢視的記錄也是一樣。當工作階段讀取記錄時，會查詢版本儲存區，以決定工作階段應該檢視的記錄版本為何。可重複讀取提供的隔離等級會在用戶端啟動交易之後，讓用戶端檢視資料庫的狀態時都是交易開始當時的狀態，而不管其他用戶端或工作階段所作的修改。可重複讀取是使用版本儲存區來實作。藉由對資料庫所作修改的記憶體內清單，可以決定特定工作階段應該檢視的記錄檢視為何。
• 延遲的前像記錄   這是一種複雜的最佳化狀況，可讓 ESE 記錄的資料比其他可比較的資料庫引擎更少。

快照集隔離

在交易開始後，ESE 會確保工作階段檢視的資料庫映像是單一且一致的，一如資料庫在交易開始時的狀態，加上本身後續的變更。由於其他工作階段也可以修改資料並認可它們的交易，在認可之前開始的任何交易不會看到這些變更。使用者只有在檢視最新的版本時才能修改記錄。否則更新會因為 JET_errWriteConflict 而失敗。比最新交易更早的版本會自動遭到捨棄。

ESE 有一項獨特的交易隔離等級，稱為「快照集隔離」。快照集隔離等級允許使用者使用資料庫的過渡性一致檢視來存取最後認可的資料列。「快照集隔離」是並行控制演算法，最早描述於 ANSI SQL 隔離等級評論 (英文) 論文中。ESE 實作快照集隔離的方法是使用可重複讀取。

ESE 資料庫結構

RTF 資料庫檔案中的所有資料儲存在 B+Tree 中。B+Tree 中的 "B" 表示是「平衡 (balanced)」。Tree (樹狀目錄) 指的是類似檔案系統上資料夾結構的安排，在這種安排中，根目錄是項目 (資料庫頁面) 的父項，而這些項目又是其他項目的父項。B+Tree 的設計是要提供對磁碟資料的快速存取。讀寫磁碟會比在記憶體中執行那些作業慢許多，因此 B+Tree 會分成 8 KB 的分頁。這讓 ESE 能夠使用最少量的磁碟 I/O 取得它所需的資料。ESE 資料庫最多可以包含 2^31 (2 的 31 次方) 個 8 KB 分頁，做為總資料庫大小上限 (大約 16 TB)。實際上，資料庫大小只受限於您及時對資料庫進行備份、還原及執行其他維護作業 (例如離線磁碟重組及資料庫修復) 的能力。

資料庫頁面

ESE 中的頁面大小是由使用它的應用程式所定義。例如，ESE98 (Exchange 2000 Server 和 Exchange Server 2003) 使用 4 KB 的頁面，而 ESENT (Active Directory) 則使用 8 KB 的頁面。這些 4 KB 或 8 KB 的頁面每一頁都包含指向其他頁面的指標，或是指向儲存在 B+Tree 中之實際資料的指標。指標和資料頁面會混雜在檔案中。

為了儘可能提高效能，頁面快取在記憶體緩衝區裡的時間會盡量地久一些。如此便降低存取磁碟的需要。每個頁面開頭是 40 個位元組的頁面標頭，包括下列值：

• pgnoThis   此值表示頁面的頁數。
• DbtimeDirtied   此值表示上次修改頁面時的 Dbtime。
• pgnoPrev   此值表示分葉左邊相鄰頁面的頁數。
• pgnoNext   此值表示分葉右邊相鄰頁面的頁數。
• ObjidFDP   此值表示資料庫中特定頁面的物件識別碼，此特定頁面稱為「資料頁面之父 (Father of the Data Page，FDP)」，它表示此頁面所屬的 B+Tree。FDP 頁面用於修復期間。
• cbFree   此值表示頁面上可用的位元組數。
• cbUncommittedFree   此值表示頁面上可用的未認可位元組數 (可用但是可供復原收回的位元組)。
• ibMicFree   此值表示在頁面頂端下個可用位元組的頁面位移。

ECC 總和檢查碼

「錯誤更正碼 (ECC) 總和檢查碼」能夠用來更正資料庫頁面中的單一位元錯誤 (在 .edb 檔案中)。

它是由兩個 32 位元的總和檢查碼所構成。第一個是 XOR 總和檢查碼，在計算中使用頁數作為種子。第二個 32 位元的總和檢查碼是 ECC 總和檢查碼，它允許更正頁面上的單一位元錯誤。

資料庫一致性與 -1018 錯誤

在讀取頁面時，ESE 會檢查頁面上的標幟，查看頁面是否具有最新的總和檢查碼格式。然後會計算適當的總和檢查碼。如果總和檢查碼與目前格式的總和檢查碼不符，ESE 會嘗試更正錯誤。如果無法自動更正錯誤，Exchange 會報告 -1018 錯誤。

如果 Exchange 儲存區執行下列其中一項，則 Exchange 儲存區可能是自行產生之 -1018 錯誤的原因：

• 建構具有錯誤總和檢查碼的頁面。
• 正確建構頁面，但告訴作業系統將頁面寫入錯誤的位置。

如果系統管理員遇到 -1018 錯誤，或是對伺服器執行診斷硬體測試，而這些測試回報沒有問題，系統管理員可能會判定 Exchange 必須為問題負責，因為硬體通過了初步的分析。

Microsoft 或硬體廠商的其他調查經常發現硬體、韌體或裝置驅動程式中的細微問題，它們實際上是損壞資料庫檔案的原因。

基於某些原因，普通的診斷測試有可能無法偵測到所有的暫時性錯誤。韌體或驅動程式軟體中的問題可能不在診斷程式的能力範圍之內。診斷測試可能無法充分地模擬長時間執行或複雜的負載。此外，加入診斷監視或除錯記錄，也可能適度地改變系統，而防止問題再次發生。

產生總和檢查碼及將頁面寫入資料庫檔案的 Exchange 機制很簡單且穩定，因此 -1018 錯誤可能是由 Exchange 以外的其他事物所導致。總和檢查碼及錯誤頁面偵測機制很簡單而可靠，並且自從第一個 Exchange 版本起即維持完全相同，只除了有些小變更，以便適應資料庫版本之間的資料庫頁面格式變更。

針對即將寫入磁碟的頁面會產生總和檢查碼－在包括頁數本身的所有其他資料都寫入頁面之後。Exchange 將總和檢查碼新增至頁面後，它會指示 Microsoft Windows Server 作業系統使用標準、已發行的 Windows Server API 將頁面寫入磁碟。

頁面可能正確地產生總和檢查碼，但該頁面卻可能寫入硬碟上的錯誤位置。這可能是由於短暫的記憶體錯誤所致，例如「位元翻轉」。比方說，假設 Exchange 建構了新版本的頁面 70。頁面本身沒有錯誤，但磁碟控制器或作業系統使用的頁數複本被隨機變更。如果不穩定的記憶體儲存格將 70 (二進位的 1000110) 變更為 6 (二進位的 000110)，便可能發生此問題。頁面的總和檢查碼仍然正確，但頁面在資料庫中的位置現在錯誤了。Exchange 針對頁面回報 -1018 錯誤，因為它偵測到邏輯頁數不符合頁面的實體位置。

另一種頁數錯誤 (Exchange 所致) 則可能發生在 Exchange 在頁面本身上寫入了錯誤的頁數之時。但這會導致其他的錯誤，而不是 -1018 錯誤。如果 Exchange 在頁面 70 上寫入了 71，然後為頁面正確地執行總和檢查碼，頁面會被寫入位置 71 並同時通過頁數及總和檢查碼測試。

Exchange 資料庫中回報的單一 -1018 錯誤通常不會導致資料庫停止，或是造成出現 -1018 錯誤本身以外的徵兆。頁面可能是在不常存取的資料夾中 (例如寄件備份或刪除的郵件資料夾)，或是在很少開啟或甚至是空的附件中。

儘管單一 -1018 錯誤不太可能導致大量資料流失，-1018 錯誤仍值得關注，因為 -1018 證明了您的儲存系統至少有一次並未可靠地儲存或擷取資料。雖然 -1018 錯誤可能是不會再發生的短暫問題，但更可能的是這個錯誤是將逐漸惡化之問題的早期警告。即使第一個 -1018 錯誤發生於資料庫中的空白頁，您也無從得知下一個毀損的頁面會發生在何處。如果重要的全域資料表損壞，資料庫可能無法啟動，而資料庫修復可能部份或完全無法順利成功。

記錄了 -1018 錯誤之後，您必須考慮並計畫即將發生失敗的可能性，或是其他對資料庫的隨機損壞，直到您找到並消除根本原因為止。

資料庫樹狀目錄平衡

ESE 的主要功能之一是隨時保持資料庫樹狀目錄平衡。平衡樹狀目錄的過程會在所有頁面都分割或合併時完成。如同下圖中所示，樹狀目錄的根目錄等級和分葉等級一定會有相同數量的節點。因此，樹狀目錄是平衡的。

平衡的樹狀目錄

從 ESE 的角度來看，資料庫資料表是 B+Tree 的集合。每個資料表由一個包含資料的 B+Tree 構成，不過可以使用許多次要索引 B+Tree 來提供不同的資料檢視。如果資料表中的資料行或欄位太寬無法儲存在 B+Tree 中，會分成另一個 B+Tree，稱為長數值樹狀目錄。

這些資料表的定義及其相關的 B+Tree 會儲存在另一個 B+Tree，稱為系統類別目錄。遺失系統類別目錄是嚴重的問題。因此，ESE 會在每個資料庫中為此 B+Tree 保留兩份相同的複本。

分割

當頁面幾乎全滿時，大約一半的資料會放在次要頁面，並在次要頁面的父系頁面放入額外的索引鍵。除非父系頁面也滿，否則都會執行這個程序。在此時，父系頁面會分割，並在此頁面的父系頁面新增指標。最後直到根目錄區塊的每個指標頁面可能都需要分割。如果根目錄區塊需要分割，則會在樹狀目錄中插入額外等級的頁面。比喻地說，樹狀目錄長高了。

合併

當頁面幾乎全空時，它會與相鄰的頁面合併，而父系頁面中的指標會更新，且如果必要的話，頁面便合併。最後，如果直到根目錄區塊的每個指標頁面都合併了，樹狀目錄便會變矮。為了取得分葉 (資料)，ESE 會從根節點開始，並遵循頁面指標，直到到達想要的分葉節點。

展開傳送

ESE B+Tree 的樹狀目錄結構具有很高的展開傳送。高展開傳送表示 ESE 可以取得 50 GB 資料表中的任何資料，而不用超過四次磁碟讀取 (三次指標頁面，一次資料頁面本身)。ESE 針對每個 4 KB 頁面儲存超過 200 個頁面指標，讓 ESE 能夠使用父/子系層數最少的樹狀目錄 (也稱為淺層樹狀目錄)。ESE 也儲存目前樹狀目錄的索引鍵，讓 ESE 能快速搜尋目前的樹狀目錄。之前的圖是具有三層父系/子系等級的樹狀目錄；具有四層父系/子系等級的樹狀目錄可以儲存許多 GB 的資料。

索引

傳統的 B+Tree 只有以一個特定方式來進行索引。它使用一個索引鍵，而資料必須使用該索引鍵擷取。例如，郵件資料表中的記錄以郵件的唯一識別碼進行索引，稱為郵件傳輸服務 (MTS)-ID。然而，使用者可能會想使用比較人性化的排序格式來檢視郵件資料表內的資料。

索引，或更明確地說－次要索引，是用來擷取資料。每個次要索引都是另一個 B+Tree，將所選擇的次要索引鍵對應到主要索引鍵。這使得 B+Tree 與它們索引的資料相比顯得較小。

若要了解如何使用次要索引，請思考當使用者變更郵件在郵件資料夾中的顯示方式時，將發生哪些事情。如果您變更 Outlook 中的資料夾檢視，以主旨來排序檢視，而不是收到的時間，Outlook 會使得儲存區及 ESE 針對您的郵件資料夾資料表建立新的次要索引。

當您第一次在大型資料夾上變更檢視時，會遇到延遲。如果仔細觀察伺服器，您會在磁碟活動中看到小量的增加。當您再次切換到該檢視時，索引已經建立，因此回應會快上許多。

Microsoft Exchange Information Store 服務的次要索引 B+Tree 可存留 8 天。如果沒有用到，Microsoft Exchange Information Store 服務會在背景作業中刪除它們。

長數值

ESE 中的資料行或記錄不能跨越資料 B+Tree 中的多個頁面。有些值 (例如 PR_BODY，這是郵件的郵件內文) 會超出頁面的 4KB 界限。這些稱為長數值 (LV)。資料表的 Long 數值 B+Tree 用來儲存這些大型的值。

如果資料輸入到 ESE 資料表，而它太大無法放入資料 B+Tree，便會分成 4 KB 大小的頁面並儲存在資料表的個別長數值 B+Tree。資料 B+Tree 中的記錄包含了指向長數值的指標。這個指標稱為長數值識別碼 (LID)，表示記錄具有指向 LID 256 的指標。

記錄格式

B+Tree 的集合代表了資料表，而資料表是資料列的集合。資料列也稱為記錄。記錄由許多資料行所構成。記錄的大小上限，也就是單一記錄中出現的資料行數量，取決於資料庫分頁大小扣掉標頭大小所得的數目。ESE 的頁面大小為 4 KB。因此，記錄大小上限大約為 4,050 個位元組 (4,096 個位元組，減掉頁面標頭的大小)。

資料行資料類型

每個資料行定義必須指定資料行中儲存的資料類型。ESE 支援下表中所描述的資料類型。

可延伸儲存引擎資料行資料類型

資料行資料類型分成兩類。第一類是固定與變動資料行。第二類是標籤資料行。每個資料行是定義為 16 個位元組的 FIELD 結構，加上資料行名稱的大小。

在 ESE 資料庫中建立資料表時，資料表是使用 FIELD 結構的陣列來定義。這個陣列識別了資料表中的個別資料行。在此陣列中，每個資料行透過一個索引值來呈現，稱為資料行識別碼。這類似一般的陣列，您可以依識別碼來參照陣列成員，例如 array[0]、array[1] 等等。可以依識別碼快速地存取資料行，但若要依據資料行名稱進行搜尋，則須對 FIELD 結構的陣列進行線性掃描。

固定與變動資料行

固定資料行包含固定的資料長度。每個記錄會佔據定義的記錄空間量，即使未定義值亦然。資料類型識別碼 1 到 10 可以定義為固定資料行。每個資料表可以定義多達 126 個固定資料行 (資料行識別碼 1 到 127)。

變動資料行可以包含多達 256 個位元組的資料。記錄中會儲存位移陣列，並設定最高的變更資料行。每個資料行需要兩個位元組。資料類型識別碼 10 和 11 可以定義為變動資料行。每個資料表可以定義多達 127 個變動資料行 (資料行識別碼 128 到 256)。

標籤資料行

ESE 將很少出現的資料行或是在單一記錄中有多個出現項目的資料行定義為標籤資料行。未定義的標籤資料行並不會造成空間的額外負荷。標籤資料行可以在相同記錄中有重複的出現項目。如果次要索引中出現了標籤資料行，資料行的每個不同出現項目都會被索引參照。

標籤資料行可以包含無限制、變動長度的資料。資料行識別碼和長度會與資料一起儲存。所有資料類型都可以定義為標籤資料行。每個資料表可以定義多達 64,993 個的標籤資料行。

若要確保您目前閱讀的是最新資訊，並尋找其他的 Exchange Server 2007 說明文件，請造訪 Exchange Server 技術資源中心.