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

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

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

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