Log文件的作用 我們討論Exchange Server的郵件存儲，就不得不談?wù)勊娜罩疚募Ｎ也恢挂淮蔚穆牭紼xchange Server的管理員抱怨：日至文件每天都在瘋長，太消耗硬盤空間了。 我們來看看這些日志文件到底有些什么作用。對于每一個Storage Group，Exchange Server會產(chǎn)生一系列與之對應(yīng)的日志文件。這些日志文件的大小為5M，擴展名為log，他們的前綴為E0x,其中x是日志文件所對應(yīng)的Storage Group的編號[腳注:雖然在Storage Group的屬性中有“Log File Prefix”這一個文本框，但實際上這是不能更改的。]。因此第一個Storage Group的日志文件前綴為E00，第二個的為E01，依次類推。這樣做的目的是當存在多個Storage Group時，可以避免管理員在維護的時候把日志文件”張冠李戴”。另外，除了連續(xù)的Log文件，我們還能看到E0x.chk、Res1.log、 Res2.log等文件。 很多管理員都對日志文件非常的頭疼，那么，微軟在Exchange Server的數(shù)據(jù)庫系統(tǒng)中引入Log文件的目的是什么呢？我們從以下幾個方面來看： 1.作為一個企業(yè)級的郵件數(shù)據(jù)庫系統(tǒng)，必須做到數(shù)據(jù)安全和完整性的萬無一失。必須能夠面對隨時可能發(fā)生的崩潰和宕機，What happens if we crash? 要能夠把數(shù)據(jù)的損失減少到最新程度。 2.必須提供高性能的郵件吞吐能力，對數(shù)據(jù)庫中的郵件的事務(wù)操做在完成后必須馬上被記錄到存儲介質(zhì)上（事務(wù)的持久性）。 3.當災(zāi)難發(fā)生時，使用數(shù)據(jù)庫的備份恢復(fù)必須要返回到災(zāi)難發(fā)生前一刻的數(shù)據(jù)庫狀態(tài)。 現(xiàn)在我們更進一步的來看一下，當我要修改郵箱中的內(nèi)容時，被修改的內(nèi)容首先被讀取出來放到內(nèi)存中。實際的修改發(fā)生在內(nèi)存中，當修改完成后，這些內(nèi)容必須被寫回存儲介質(zhì)，才能表示一個修改成功地完成了。 對于這樣的修改過程，在數(shù)據(jù)庫級別上，我們叫做一個“事務(wù)”。我們知道，為了確保數(shù)據(jù)庫的完整性和一致性，事務(wù)的操作是“原子級別”的。如果一個事務(wù)成功，那么標志著他所作的改變被永久的保存下來了；如果一個事務(wù)失敗，系統(tǒng)必須回到事務(wù)開始之前的狀態(tài)。 當系統(tǒng)在內(nèi)存中完成修改時，事務(wù)并沒有完成。如果這個時候宕機，數(shù)據(jù)庫中保存的仍然是沒有更改的內(nèi)容。那么，怎么樣確保在內(nèi)存中完成的修改能夠在第一時間寫入到數(shù)據(jù)庫呢（以達到數(shù)據(jù)庫事務(wù)持久性的要求）？注意，這里的要是第一時間，也就是越快越好。如果我們直接向edb文件寫入，無法做到最快，因為，edb 文件通常都很大，I/O系統(tǒng)在對大的文件進行隨機寫入操作時，會花費大量的時間在等待磁盤查找到合適的磁道和扇區(qū)，當系統(tǒng)繁忙時，這將會是一個瓶頸。因此，數(shù)據(jù)庫系統(tǒng)使用日志文件，當內(nèi)存中的更改完成后，首先寫入到日志文件中。日志文件的尺寸很小，寫入性能要遠遠優(yōu)于龐大的edb文件。在寫入完成后，事務(wù)也隨之成功的保存在存儲介質(zhì)上了。Exchange Server 的數(shù)據(jù)庫引擎會在后臺把Log文件中的內(nèi)容寫入到數(shù)據(jù)庫中，因為此時事務(wù)操作已經(jīng)完成，即使此時掉電或者宕機，也不會使完成的事務(wù)遺失。這是日志文件的第一個作用：確保事務(wù)能夠在第一時間保存到非易失存儲介質(zhì)上。（提供持久性Durable支持） 根據(jù)上面的描述，我們知道在運行中的Exchange Server數(shù)據(jù)庫，是由三部分組成的 －－內(nèi)存中已經(jīng)完成修改但是還沒有寫入日志文件的內(nèi)容（Dirt Page）。 －－還沒有寫入到數(shù)據(jù)庫文件的日志文件內(nèi)容。 －－Edb和stm文件。 對于內(nèi)存中的數(shù)據(jù)（Dirt Page），這些數(shù)據(jù)會在系統(tǒng)掉電或者崩潰時遺失。 Exchange Server使用了一個名為E0x.chk（Check Point）的文件記錄了那些Log文件已經(jīng)寫入到了數(shù)據(jù)庫文件。這是一個類似指針的記錄。

我們可以使用命令 ESEUTIL /MK來查看這個文件chk的內(nèi)容

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>表示了當前提交到數(shù)據(jù)庫文件的Log完全位置。其中，0x8是Log文件的序號，一般對應(yīng)于E0x00008.log,剩下的兩個參數(shù)是Log文件內(nèi)部頁面（page）的編號。 下面我們再看一下日志文件對系統(tǒng)備份和恢復(fù)的作用。 前面提到過，Exchange Server要求在災(zāi)難發(fā)生后能夠恢復(fù)到災(zāi)難發(fā)生前一刻的狀態(tài)。對于一般的系統(tǒng)，我們總是每周或者每天進行備份，那么，在備份之后和災(zāi)難發(fā)生之前這段時間的數(shù)據(jù)如何保護？答案是日志文件。我們知道，對于數(shù)據(jù)庫的任何更改，都會先被寫入到日志文件，然后再由日志文件更新到數(shù)據(jù)庫中。我們現(xiàn)在假設(shè)有這樣一套系統(tǒng)，在每天的3:00 AM進行備份，備份完成后，系統(tǒng)正常運轉(zhuǎn)。如果在中午12:00的時候系統(tǒng)出現(xiàn)故障，管理員用3:00AM的磁帶恢復(fù)了系統(tǒng)，那么，從3:00AM到 12:00AM這段時間的數(shù)據(jù)，將由log文件來填補的。具體的情況是，當3:00AM的備份恢復(fù)完成后，Exchange Server會自動掃描到跟這個store相關(guān)聯(lián)的日志文件夾，如果發(fā)現(xiàn)有比當前數(shù)據(jù)庫還新的日志存在，Exchange Server會自動把這些日志按照順序?qū)懭氲綌?shù)據(jù)庫中。因此，從3:00AM到12:00AM這段時間對數(shù)據(jù)庫所作的更改，可以被恢復(fù)回來。這是日志文件第二個重要的作用。（前提是沒有開啟循環(huán)日志功能） 有人可能會問，如果數(shù)據(jù)庫文件和日志文件同時損壞怎么辦？答案是這樣的：避免這種情況發(fā)生。首先，數(shù)據(jù)庫文件損壞的概率要遠遠大于日志文件，另外，微軟推薦的做法是把數(shù)據(jù)庫文件和日志文件分別放置在不同的磁盤上。我們會在下一期的文章中著重討論這個問題。 管理員針對日志文件的抱怨是，這些文件會每天不斷的增長，大量消耗硬盤空間。對于這個問題，唯一合理的解決辦法是：定期的做針對Storage Group的全備份或增量備份。因為Exchange Server會在全備份或增量備份完成后把這次備份之前產(chǎn)生的Log文件全部刪除。很多管理員手動的刪除日志文件，或者啟動“循環(huán)日志”來減少對硬盤空間的消耗，這都是不正確的做法。殘缺不全的日志文件會使系統(tǒng)在進行備份恢復(fù)的時候無法還原到最近的狀態(tài)。如果你的系統(tǒng)是一周做一次全備份，而你碰巧又在備份后刪除了一些日志文件，那么你就有可能在需要恢復(fù)的時候丟失備份以后的數(shù)據(jù)。記住，數(shù)據(jù)總是比磁盤空間更寶貴。 ESE數(shù)據(jù)庫引擎以及Information Store服務(wù)的啟動和關(guān)閉 在ESE 引擎加載數(shù)據(jù)庫文件時，它會檢查數(shù)據(jù)庫文件的一個特殊標志位。這個標志位保存了數(shù)據(jù)庫文件上次是否被正常關(guān)閉。這個狀態(tài)由“ Consistent”或“ Inconsistent”來表示。對于一個正常關(guān)閉的數(shù)據(jù)庫文件，所有在Log文件和內(nèi)存中的內(nèi)容都應(yīng)該已經(jīng)提交到數(shù)據(jù)庫文件中，只有在這個時候，數(shù)據(jù)庫才會被標記為“ Consistent”。有一點需要注意，在運行中的數(shù)據(jù)庫，它的狀態(tài)一定是“ Inconsistent”，因為在Log文件中肯定還有沒提交到數(shù)據(jù)庫文件內(nèi)容。對于一個已經(jīng)關(guān)閉并且狀態(tài)被標示為“ Inconsistent”的數(shù)據(jù)庫，并不意味著這個數(shù)據(jù)庫庫文件損壞了，“ Inconsistent”只是表示，還有未曾寫入到數(shù)據(jù)庫文件的內(nèi)容保存在Log文件中。 使用命令 ESEUTIL /MH可以查常看數(shù)據(jù)庫的關(guān)閉狀態(tài)。

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 <-----表示數(shù)據(jù)庫關(guān)閉時的狀態(tài) Log Required: 0-0 Streaming File: Yes Shadowed: Yes Last Objid: 574 …<略> … Operation completed successfully in 1.391 seconds.

State字段的“Clean Shutdown”表示數(shù)據(jù)庫處在Consistent狀態(tài)。 當ESE 加載數(shù)據(jù)庫文件時，對于“Consistent”的數(shù)據(jù)庫文件，它直接Mount其中的Store；對于“In consistent”的數(shù)據(jù)庫文件，ESE將執(zhí)行稱之為“Soft Recovery”的過程，在這個過程中，未及時提交進數(shù)據(jù)庫文件的日志內(nèi)容將被寫入數(shù)據(jù)庫。當所有的日志都寫入完畢，數(shù)據(jù)庫才會被標記為“ Consistent”狀態(tài)，然后正常加載。 Soft Recovery開始的時候，ESE會根據(jù)check point文件所指向的位置來進行Log文件的寫入(如果check point文件也損壞或者不存在，那么數(shù)據(jù)庫就從最舊的Log文件開始)。當ESE從Log文件向Store寫入數(shù)據(jù)時，它會根據(jù)dbTime這個時間戳來決定是否需要把Log文件寫入到數(shù)據(jù)庫。

原文出處 http://bbs.5dmail.net (中文名稱:5Dmail郵件資訊網(wǎng))

淺談Exchange Server郵件存儲系統(tǒng)-原理篇(2)