Log文件的作用 我們討論Exchange Server的郵件存儲,就不得不談談它的日志文件。我不止一次的聽到Exchange Server的管理員抱怨:日至文件每天都在瘋長,太消耗硬盤空間了。 我們來看看這些日志文件到底有些什么作用。對于每一個Storage Group,Exchange Server會產生一系列與之對應的日志文件。這些日志文件的大小為5M,擴展名為log,他們的前綴為E0x,其中x是日志文件所對應的Storage Group的編號[腳注:雖然在Storage Group的屬性中有“Log File Prefix”這一個文本框,但實際上這是不能更改的。]。因此第一個Storage Group的日志文件前綴為E00,第二個的為E01,依次類推。這樣做的目的是當存在多個Storage Group時,可以避免管理員在維護的時候把日志文件”張冠李戴”。另外,除了連續的Log文件,我們還能看到E0x.chk、Res1.log、 Res2.log等文件。 很多管理員都對日志文件非常的頭疼,那么,微軟在Exchange Server的數據庫系統中引入Log文件的目的是什么呢?我們從以下幾個方面來看: 1.作為一個企業級的郵件數據庫系統,必須做到數據安全和完整性的萬無一失。必須能夠面對隨時可能發生的崩潰和宕機,What happens if we crash? 要能夠把數據的損失減少到最新程度。 2.必須提供高性能的郵件吞吐能力,對數據庫中的郵件的事務操做在完成后必須馬上被記錄到存儲介質上(事務的持久性)。 3.當災難發生時,使用數據庫的備份恢復必須要返回到災難發生前一刻的數據庫狀態。 現在我們更進一步的來看一下,當我要修改郵箱中的內容時,被修改的內容首先被讀取出來放到內存中。實際的修改發生在內存中,當修改完成后,這些內容必須被寫回存儲介質,才能表示一個修改成功地完成了。 對于這樣的修改過程,在數據庫級別上,我們叫做一個“事務”。我們知道,為了確保數據庫的完整性和一致性,事務的操作是“原子級別”的。如果一個事務成功,那么標志著他所作的改變被永久的保存下來了;如果一個事務失敗,系統必須回到事務開始之前的狀態。 當系統在內存中完成修改時,事務并沒有完成。如果這個時候宕機,數據庫中保存的仍然是沒有更改的內容。那么,怎么樣確保在內存中完成的修改能夠在第一時間寫入到數據庫呢(以達到數據庫事務持久性的要求)?注意,這里的要是第一時間,也就是越快越好。如果我們直接向edb文件寫入,無法做到最快,因為,edb 文件通常都很大,I/O系統在對大的文件進行隨機寫入操作時,會花費大量的時間在等待磁盤查找到合適的磁道和扇區,當系統繁忙時,這將會是一個瓶頸。因此,數據庫系統使用日志文件,當內存中的更改完成后,首先寫入到日志文件中。日志文件的尺寸很小,寫入性能要遠遠優于龐大的edb文件。在寫入完成后,事務也隨之成功的保存在存儲介質上了。Exchange Server 的數據庫引擎會在后臺把Log文件中的內容寫入到數據庫中,因為此時事務操作已經完成,即使此時掉電或者宕機,也不會使完成的事務遺失。這是日志文件的第一個作用:確保事務能夠在第一時間保存到非易失存儲介質上。(提供持久性Durable支持) 根據上面的描述,我們知道在運行中的Exchange Server數據庫,是由三部分組成的 --內存中已經完成修改但是還沒有寫入日志文件的內容(Dirt Page)。 --還沒有寫入到數據庫文件的日志文件內容。 --Edb和stm文件。 對于內存中的數據(Dirt Page),這些數據會在系統掉電或者崩潰時遺失。 Exchange Server使用了一個名為E0x.chk(Check Point)的文件記錄了那些Log文件已經寫入到了數據庫文件。這是一個類似指針的記錄。
我們可以使用命令 ESEUTIL /MK來查看這個文件chk的內容
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. |
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 <-----表示數據庫關閉時的狀態 Log Required: 0-0 Streaming File: Yes Shadowed: Yes Last Objid: 574 …<略> … Operation completed successfully in 1.391 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文件寫入到數據庫。
原文出處 http://bbs.5dmail.net (中文名稱:5Dmail郵件資訊網)
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
