瞭解與分析-1018年、-1019年及-1022 Exchange 資料庫錯誤

文章翻譯 文章翻譯
文章編號: 314917 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

在此頁中

結論

本文提供的資訊來幫助您瞭解與分析-1018年、-1019年及-1022 Exchange 資料庫錯誤。本文將告訴之間的差異這三種錯誤,以及問題的類型在資料庫中,會造成每個報告這三種錯誤。

其他相關資訊

Exchange 會包含在其資料庫中偵測到網頁的檔案層級損毀的功能。三個最常見的錯誤檔案層級損毀 Exchange 資料庫與相關聯的如下所示:
  • -1018 JET_errReadVerifyFailure
  • -1019 JET_errPageNotInitialized
  • -1022 JET_errDiskIO
下列三個層級的傷害可能發生在 Exchange 資料庫:
  • 網頁 (檔案系統) 層級
  • 資料庫 (JET 資料庫引擎) 層級
  • 應用程式 (Exchange 資訊儲存庫) 層級
Esefile.exe 公用程式可以在頁面層級的資料庫中偵測到錯誤。Eseutil.exe 公用程式可以偵測並修復頁面層級和資料庫層級的問題。Isinteg.exe 公用程式會偵測並修復應用程式層級的問題。

較低層幾乎都在較高層級 (資料庫或應用程式層級) 的問題中的結果 (網頁層級)。因此,修復 Eseutil 與資料庫之後,您幾乎都需要使用 Isinteg 之後。

在 Exchange 程式碼或與 Exchange 相整合的協力廠商程式中的問題與相關資料庫和應用程式層級的傷害。在頁面層級的傷害通常被因為驅動程式、 韌體或硬體問題,雖然頁面層級毀損可能也會造成問題在 Exchange 中。

您幾乎都到其中一種 Exchange 取決於基礎系統的-1018年錯誤的根本原因,不在 [Exchange 代碼本身。有少數的例外狀況,這項規則。日期的例外狀況已報告-1018年條件,Exchange 就不是因為 Exchange 本身就會產生-1018年錯誤。 如需詳細資訊,按一下下面的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
237953 線上備份期間所傳回的錯誤-1018年錯誤
230215 不在單一處理器的電腦上執行備份加總檢查碼
雖然錯誤也會造成-1019年及-1022年錯誤的大部分是基礎系統中,您無法排除-1019年及-1022年錯誤可能會發生錯誤: 在 Exchange 快的程式碼的可能性。

錯誤-1018年是最常見的錯誤,表示 Exchange 資料庫發生檔案系統層級的傷害。因此,大部分的這篇文章著重於錯誤-1018年。

有三種基本可能性磁碟上的資料可以損毀:
  • 錯誤的資料會寫入存放媒體。
  • 資料在儲存媒體寫入錯誤的位置。
  • 資料已損毀,或後儲存變更。
雖然很難預防或更正所有毀損的 100%,但是它是相當容易偵測已經發生的問題。Exchange 會在其資料庫檔案中偵測到不正確和放錯位置的資料,並報告-1018年錯誤或-1019年錯誤。如果檔案已經嚴重毀損,它的組件完全遺失或是無法存取 Exchange 嘗試讀取檔案時,會報告-1022年錯誤。

Exchange 會加總檢查碼和數字的計算資料庫頁面

若要瞭解觸發-1018年及-1019年錯誤的機制的運作方式,您必須了解如何將 Exchange 資料庫儲存資料頁。

最低邏輯層級,您可以檢視 Exchange 資料庫檔案為一組 4 千位元組 (KB) 頁面,依照連續順序編號。資料是讀取和寫入 Exchange 資料庫的一頁,一次。

含有資料的每個頁面會儲存自己的頁數,以及在頁面上所計算出來的所有資料的總和檢查碼。總和檢查碼值本身是不包含在這個計算頁面的唯一部份。

總和檢查碼演算法,包括 Exchange 所使用的總和檢查碼演算法是很清楚和相當簡單。它們設計對任何兩個不同的頁面將會產生相同的總和檢查碼的可能性很低,,即使在頁面之間的差異只會有一個位元。

雖然總和檢查碼測試足以用來寫入之後已經變更頁面,總和檢查碼測試不足以確定網頁是在正確的位置。因此,Exchange 加上戳記每一頁,其本身的頁數以及總和檢查碼。

在資料庫中的前兩個 4 KB 頁面被保留給資料庫 」 標頭 」。當資料庫被停止時,您可以使用 Eseutil 公用程式/MH參數,若要檢視此標頭。標頭包含整個資料庫的識別資訊。

這些前兩個標頭網頁中,所有在資料庫中的其他網頁後的資料。資料頁面全部共用常見的結構。每一頁有它自己頁首,其中含有關於特定頁面,後面接著實際資料的識別資訊。

因為 Exchange 資料庫中的第一資料頁所在的第一個的兩個標頭頁面之後,資料庫中的實體頁面 3 是邏輯第 1 頁。2 是邏輯頁數的實體頁面 4,依此類推。

在資料庫中的邏輯頁數直接對應到實體頁數依照下列公式:
邏輯頁數 = 實體頁數-2
因為資料庫檔案的邏輯與實體頁面結構因此密切相關,Exchange 可以輕易地判斷每個邏輯頁面是否在檔案中的正確實體位置。

無法計算總和檢查碼的資料庫中的唯一網頁是 「 未初始化的頁面 」。這些是區塊的資料庫大小將會擴充以騰出空間給更多的資料時所建立的網頁。未初始化的頁面是指具有零總和檢查碼和零頁數。一般而言,每個位元組的未初始化的頁面會填滿字元0x00

未初始化的頁面用於第一次之後,它不會傳回未初始化的狀態,即使它清空。相反地,旗標是空白的頁面上設定將其標示為可以重複使用。頁面仍然會具有頁數及總和檢查碼,即使是空白的。

總和檢查碼演算法和所使用的頁面格式,就會變更 Exchange Server 2003 Service Pack 1 (SP1)。此外,Exchange Server 2003 SP1 引入錯誤修正碼 (ECC) 演算法來偵測,並自動修正單一位元錯誤。如需有關這項新功能的詳細資訊,請按一下下面的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
867626 新的錯誤修正程式碼包含在 Exchange Server 2003 Service Pack 1

什麼會造成-1018年錯誤

Exchange 會報告-1018年錯誤時,資料庫檔案中的未初始化頁面發現有下列情況之一:
  • 儲存在頁面的總和檢查碼不符所讀取的頁執行總和檢查碼重新計算的結果。
  • 儲存在頁面的頁碼不符,應該在頁面上,指定網頁的實體位置,資料庫檔案中的頁碼。
可能就會自行產生-1018年錯誤,如果 Exchange 執行下列其中一項:
  • 建構有錯誤的總和檢查碼的網頁。
  • 正確,建構頁面,但是告訴作業系統在錯誤的位置寫入頁面。
系統管理員發現-1018年錯誤,如果系統管理員對伺服器執行診斷硬體測試,而這些測試報告沒有問題之後,系統管理員可以斷定 Exchange 必須負責問題,因為硬體通過了初始化分析。

不過,如果在之後的情況下,您可以進一步調查由 Microsoft 或硬體廠商細小問題實際上負責造成資料庫檔案的硬體、 韌體或裝置驅動程式中。

一般診斷測試可能無法偵測出所有暫時性錯誤,原因。韌體或驅動程式軟體中的問題可能會超出的診斷程式功能。診斷測試可能無法完全模擬長執行時間或複雜的負載。此外,新增診斷監視或偵錯記錄可能會變更系統,從而防止問題再度出現。

簡單又穩定的 Exchange 機制能夠產生總和檢查碼和頁面寫入資料庫檔案是-1018年錯誤的根本原因為 Exchange 問題的可能性很低的另一個原因。總和檢查碼不正確的頁面偵測機制既簡單又可靠和仍十分基本上相同因為第一個 Exchange 發行,但不包括以適應資料庫版本之間資料庫頁面格式變更的次要變更。

此外,說明頁面寫入磁碟的所有其他資料寫入至頁面之後,就會產生總和檢查碼,包括頁數代碼本身。Exchange 會將總和檢查碼加入網頁之後,Exchange 會指示 Microsoft Windows 作業系統將頁面寫入磁碟,藉由使用標準、 發行 Windows 應用程式發展介面 (Api)。

總和檢查碼可能會產生正確] 頁面上,但再頁面可能會寫入錯誤的位置在硬碟上。這可能被因暫時性記憶體錯誤,例如"位元翻轉]。例如,假設 Exchange 建構了頁面 70 的新版本。網頁本身不會遇到錯誤,但隨機變更複本的磁碟機控制卡或作業系統所使用的頁碼。如果不穩定的記憶體儲存格 70 (二進位是 100110) 變更為 6 (二進位是 000110),可能會發生這個問題。頁面的總和檢查碼還是正確的但在資料庫中的網頁位置現在已經是錯誤。當它偵測到的邏輯頁數不符合頁面的實體位置時,Exchange 就會報告-1018年錯誤頁面。如果 Exchange 會在網頁本身上寫入錯誤的頁碼,可能會發生另一種頁碼編排方式 (Exchange 所造成) 的錯誤。但是,這會造成其他錯誤,錯誤-1018年錯誤。如果 Exchange 在頁面 70 上寫入 71,然後正確地不會在頁面上的總和檢查碼,網頁會寫入位置 71,並通過頁面數與總和檢查碼測試。

通常,報告 Exchange 資料庫中的單一-1018年錯誤並不會導致資料庫停止,或造成-1018年錯誤本身存在以外的徵狀。頁面可能是在不常存取的資料夾 (例如,寄件備份] 或 [刪除的項目資料夾),或很少會開啟,或甚至是空白的附件中。

雖然單一的-1018年錯誤不太可能會造成大量的資料遺失,但-1018年錯誤仍是問題的原因因為-1018年錯誤證明您的儲存系統無法確實地儲存,或至少一次擷取資料。雖然-1018年錯誤可能會發生過一次的暫時性問題,更可能是問題的這個錯誤就會變得更糟的早期警告。即使第一次的-1018年錯誤是在資料庫中的空白頁面上,您無法知道哪一頁可能因為接下來的損壞了。如果重要的通用表格毀損了,資料庫可能會變得無法,而且資料庫修復可能失敗或只有部分成功。

記錄-1018年錯誤之後,您必須考慮,並準備即將發生故障或隨機損害到資料庫的可能性,直到您找出並消除根本原因。

從-1018年錯誤中修復

Exchange 會將完全無法讀取,以防止對隨機資料的動作導致進一步問題資料庫中的-1018年錯誤而失敗的頁面。

無法修復或再利用-1018年錯誤而失敗的頁面。它必須是從資料庫中加以刪除。有三種方法,您可以使用頁面從資料庫中刪除:
  • 從線上備份還原資料庫。
  • 使用 Eseutil.exe /D切換控制,若要執行離線磁碟重組的資料庫。
  • 使用 Eseutil.exe /P參數修復資料庫。

從線上備份還原資料庫

如果在線上備份期間發現-1018年錯誤,則會停止備份。這可確保已毀損的頁面不存在於最後一個成功的備份。如果停用循環記錄,則可以還原最新可用的完整備份,,然後將資料庫向前復原從後續的交易記錄。

使用 Eseutil.exe"/ D 」 切換到執行離線磁碟重組的資料庫

這個方法很有效,如果在空白的頁面報告-1018年錯誤。如果在線上備份或是夜間線上維護期間,發生-1018年錯誤,這表示頁面不常加以存取,或它可能甚至是空的。離線磁碟重組會捨棄所有的空白頁面及資料庫中的次要索引。

使用 Eseutil.exe"/ P"參數修復資料庫

如果您使用這個方法,但錯誤的頁面已被丟棄,則不會修復錯誤的頁面。如果 「 葉頁面 」 的相關資訊的頁面,就會發生遺失某些資料。資料庫中的分葉頁面是包含實際資料的資料頁。內部頁面執行只結構性及邏輯資訊。在大部分的情況下,Eseutil 可以完整地重新建構表格如果內部頁面將會遺失。然而,大部份的資料庫中的頁面都是葉頁面。

Eseutil 的修復功能十分好吧,而且在大多數情況下可以將資料庫還原至最少的資料遺失的作業。不過,如果許多頁面已經毀損了,或是關鍵系統資料表將會遺失,資料遺失可能會造成重大錯誤,或資料庫可能會無法加以修復。

修復資料庫,通常是較差的策略,相較於從備份還原並向前復原資料庫,因為修復通常所需的時間比還原及較高的風險。只有當選擇修復:
  • 您沒有備份。
  • 您不能回復完全從您的備份。
修復或還原資料庫之前,一定要目前的資料庫檔案的備份複本。如果還原無法運作,您可以修復現有的資料庫。如果修復無法運作,但仍然啟動前一份資料庫,您可能無法挽救資料,否則會遺失。

重要修復資料庫之後,您必須檢查資料庫標頭中的修復計數。如果 count 是大於零,您必須使用 Eseutil,來執行離線磁碟重組,然後,您必須修復 Isinteg 公用程式與資訊儲存庫層級的資料庫。如果不這麼做,使用者可能會遇到的問題,例如無法在他們的信箱不存在的項目中開啟郵件或附件或參考。

若要檢查修復計數,請檢查您執行下列命令時,會產生螢幕輸出:
ESEUTIL /MH [database_file_name]
若要執行離線磁碟重組的經過修復的資料庫,執行下列命令:
ESEUTIL /D [database_file_name]
若要執行完整的 Isinteg 修正在修復後在 Exchange 2000,必須執行資訊儲存庫服務,不過也必須卸載您想要修復的資料庫。執行下列命令,以修正資料庫:
ISINTEG-S [server_name]-修正-測試 ALLTESTS
若要執行完整的 Isinteg 修正在修復後在 Exchange Server 5.5 中,服務必須先停止資訊儲存庫。執行下列命令,使用適當的參數 (優先-PUB),視您是否對私人或公用資料庫執行修復:
ISINTEG-PRI|發行端點的修正-測試 ALLTESTS
附註您可以執行 Eseutil 和 Esefile 對原始資料庫檔案,無論他們的檔案系統位置。資料庫檔案甚至不需要 Exchange 伺服器上。但是,當資料庫是在完全設定的 Exchange 伺服器上的位置,因為 Isinteg 資訊儲存庫層級的運作方式,並使用資訊儲存庫服務存取資料庫時,您必須執行 Isinteg。

如需詳細資訊,按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
244525 如何在一台沒有 Exchange Server 電腦上執行 Eseutil

從-1019年錯誤中復原

預期會在使用中頁面未初始化或空白時,會報告-1019年錯誤 (JET_errPageNotInitialized)。如果正在使用的頁面上的頁數欄位是 0x00000000,會報告-1019年錯誤而不是-1018年錯誤,即使頁面也可能無法通過總和檢查碼測試。

若要更正-1019年錯誤的方法完全一樣的-1018年錯誤。請注意-1019年問題可能會進入未偵測的介面比-1018年問題長,因為-1019年問題不會偵測到的線上備份。

雖然造成-1018年錯誤的根本原因是很有可能是 exchange,-1019年錯誤可能被因 Exchange 如果是無效的邏輯指標或頁面之間的連結。

不過,它是較常見的造成-1019年錯誤,因為檔案系統毀損,或是將頁面對應至不屬於檔案中的資料庫檔案。

從-1022年錯誤中復原

如果 Exchange 在資料庫中,頁面要求作業系統,而不是要傳回的頁面資料就會發生錯誤,造成-1022年錯誤 (JET_errDiskIO)。-1022年錯誤是每當磁碟輸入/輸出 (I/O) 問題使 Exchange 無法存取要求的網頁,在資料庫中就會顯示泛型錯誤。

-1022年錯誤最常見的原因是資料庫檔案嚴重損毀或截斷。如果發生這個問題,Exchange 會要求頁碼大於資料庫檔案中的頁數,並且出現-1022年錯誤。檔案系統中的問題,或因為不當的交易記錄重新顯示,就可能發生這個問題。

Exchange 2000 包含廣泛的防範措施以避免可能會破壞資料庫的交易記錄重新顯示,但在 Exchange Server 5.5 很可能以播放未完成組記錄檔及損毀資料庫。例如,如果從記錄檔 9,應該開始重新執行,但實際上卻強制為從記錄檔 10 開始,可能會發生這個問題。如果系統管理員刪除檢查點檔案和記錄檔 9,就會強制重新執行。如果交易記錄檔 9 中的擴充資料庫的大小,但記錄檔 9 不播放到資料庫,記錄檔 10 到新頁面加入至資料庫中的參考會造成-1022年錯誤。當機,就會停止 (擱置),並存取違規也是常見的徵狀的重新顯示不完整的交易記錄檔組都分到資料庫。

瞭解並疑難排解造成-1022年錯誤的根本原因是比疑難排解-1018年或-1019年錯誤更複雜。如果錯誤因資料庫損毀,檔案系統中,您需要確認或修復檔案系統,並從備份中還原 Exchange。雖然修復資料庫仍是一個選項,修復是比較不可能會比其他錯誤成功,因為-1022年錯誤通常表示在損毀。

到目前為止最常見的原因,與未損毀的資料庫-1022年錯誤的另一個應用程式檔案保持開啟,並防止資訊儲存庫服務無法加以存取。在這種情況下,您也可能會看到-1032 錯誤 (JET_errFileAccessDenied)。重新啟動所有的 Exchange 服務或重新啟動伺服器,可能會移除鎖定。

協力廠商程式,例如病毒掃描程式可能會封鎖存取 Exchange 來交換資料。設定檔案層級的病毒掃描軟體來交換資料檔案排除在檔案掃描作業。有數種病毒掃描,利用 Exchange 的病毒掃描應用程式發展介面 (API) 來掃描郵件和附件資訊儲存庫中的。

分析-1018年及-1019年錯誤

這一節中的資訊主要供技術支援及廠商人員都能參與根原因分析。

系統管理員發現-1018年或-1019年錯誤之後,系統管理員需要知道至少三件事:
  • 什麼是毀損的頁面上
  • 成功修復的可能是什麼
  • 在第一時間內造成原因所造成的損害
-當您啟動服務,應用程式事件記錄檔,或在 Exchange 公用程式,例如 Eseutil 輸出,在命令列可能會發生 1018年及-1019年錯誤。可能不會報告-1018年錯誤的應用程式事件記錄檔中,當您執行資料庫完整性檢查與時Eseutil /G命令。在此情況下,很可能是空的錯誤頁面。

在大部分的情況下,可讓您識別報告問題的網頁表單中會報告錯誤。您也可以掃描整個資料庫使用 Esefile 來識別錯誤頁面。 如需有關 Esefile 的詳細資訊,請按一下下面的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
248406 Exchange Server 5.5 與 Exchange 2000 Esefile 支援公用程式
下列範例是從不同版本 Exchange,以及分析中每個錯誤的詳細資料的應用程式事件記錄檔的一般-1018年錯誤說明。
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
在上述範例中,您可以解譯括號中的數字,如下所示:
  • (3106 3106) 代表已要求的頁面 (3106) 和頁碼發現實際寫入頁面 (3106 頁) 的資料庫中的頁面。1: 表示這是資料庫 1,也就是 Exchange Server 5.5 的 Priv.edb。Pub.edb 資料庫 2。
  • (0-310013) 表示目前寫入頁面的dbtime值。Dbtime值是寫入每個相關多久之後變更頁面的頁面的 64 位元值。
  • (0-312215) 表示整個資料庫的目前dbtime值: 可能dbtime值,如果頁面現在變更會寫入此頁面上。已在頁面的dbtime值應該永遠小於目前dbtime值。
假設頁碼已經正確地讀取頁面,並dbtime值是合理的 (第一個dbtime值小於第二個),此網頁已經不完全取代由資料庫外的網頁或不同的頁面。

您可以使用 Esefile 輸出頁面本身具有類似下列的命令:
Esefile /d database.edb 3106 > 3106.txt
因為此頁面顯示大體上還算結構完整,您也可以使用 Eseutil,檢視網頁的較多的邏輯資訊。您可以使用 Eseutil 的 Exchange 2000 版本,來檢視 Exchange 2000 與 Exchange Server 5.5 資料庫中的網頁結構資訊。

警告請勿將寫入資料庫的任何模式中使用 Eseutil 的 Exchange 2000 版本,與 Exchange Server 5.5 資料庫比對。為了安全起見,使用只有/M參數,並永遠不會使用/P/G/R。此外,請勿 Eseutil.exe 和 Ese.dll 的 Exchange 2000 版本複製到 Exchange Server 5.5 電腦。相反地,將這些檔案複製到遠端伺服器,並提供您正在檢查資料庫的明確命令列通用命名慣例 (UNC) 路徑。

類似下列的命令的命令會輸出至文字檔案的某一頁面的邏輯資訊:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
從這個輸出中,您可以看到該網頁是分葉分頁,這表示在其上有實際的資料。如果您修復這個資料庫,修復會導致遺失至少這項資料。 如需有關如何找出哪一個資料表或這個分頁所屬的信箱的詳細資訊,請按一下下面的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
262196 如何判斷哪個信箱擁有資料庫中的特定頁面
如果 Eseutil 輸出沒有列出分葉頁面的頁面,修復的機會將工作完全很高。可以在修復處理程序完全重新建構最內部或結構的頁面。

輸出可能也顯示為 「 空白頁面 」。在此情況下,離線磁碟重組會捨棄資料庫中的錯誤頁面。

請記住,是否頁面已經完全由不屬於資料庫檔案中的資料區塊取代,Eseutil 輸出可能是沒有意義。

下列的錯誤是另一個範例:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
在這個範例中,實際上從頁面 (3688618971) 讀取的頁碼不符合要求的頁面時,這表示頁碼所在的頁面標頭區域已經損毀。可能是頁數的頁碼甚至不存在資料庫中。若要判斷這是否為大小寫,頁數乘以 4096,,然後比較該數目的位元大小的資料庫檔案。在此情況下,頁面的頁碼不太可能是 Exchange 原來所寫入,除非資料庫是 15 tb (3688618971 x 4096 = 15108583305216) 的大小。

也請注意第一個dbtime值重複頁面頁數模式完全相同。如果您將 3688618971 轉換為十六進位 (其工程型] 模式中使用 Calc.exe) 時,它會變成 0xDBDBDBDB。在 Exchange 2000 與 Exchange Server 5.5,4 個位元組頁數值之後立即儲存 8 個位元組dbtime值。因此,您知道至少 12 個連續的位元組,對兩個不同的欄位已覆寫具有特定模式。如果您使用 Esefile 直接查看這個頁面時,可能會發現整個頁面已覆寫使用 0xDB 的模式。另一種常見的無效位元組模式是 0xFF。如果這是上述錯誤的情況, dbtime值會是 4294967295。

下列的錯誤提供為檔案中的位元組位移,而非頁碼的網頁資訊:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
您可以移除三個後端的零、 減去 1,再將結果轉換為十進位,將第一個位移轉換到的頁碼。在這個範例中,0x00000000000db-1 = 0xda = 218 十進位。您可以使用 Esefile 或 Eseutil 這個十進位的頁碼。

附註您減去只有 1,而不是 2,以說明資料庫中的兩個標頭頁面,因為位移開始 50 而不是 0x1 0x0。如果您想要檢查標頭頁面使用 Esefile 或 Eseutil,參考頁-1 和第 0 頁。

在 Exchange 資料庫標頭實際上需要只將單一網頁。第二個頁面是標頭的 「 陰影 」 複製。當您使用報告的總和檢查碼Esefile /D頁面傾印函式應永遠排在頁面-1 及 0 相同資料庫會完全關閉之後。如果在當機期間重新寫入標頭,Exchange 會使用標頭副本全新的總和檢查碼與 Exchange 重新啟動時。

現在繼續前述的範例,總和檢查碼已實際上非常接近彼此,只有兩個字元不同。加總檢查碼關閉時,這表示在頁面上所做的變更微乎其微: 可能只有一個位元發生錯誤。就很可能是此頁面仍然包含足夠的邏輯結構,使其值得使用分析Eseutil /M /P

錯誤訊息中的預期數的字是實際讀取的頁面存在於目前資料庫中的總和檢查碼。錯誤訊息中實際的總和檢查碼是 Exchange 動態重新計算讀取頁總和檢查碼。

在網頁上實際的總和檢查碼是 0x89abcdef,如果頁面包含了所有 0x00 字元。實際的總和檢查碼是 0x76543210,如果頁面包含了所有 0xFF 字元。

下列範例是-1019年錯誤:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
在一般作業期間,如果頁面報告-1019年錯誤或-1018年錯誤,-1019年錯誤的優先順序,並且報告。請記住每當寫入頁面的頁數是 0x00000000,就會發生-1019年錯誤,但 Exchange 預期頁面是使用中。就很難證明是否-1019年錯誤因為檔案系統對應到資料庫檔案中,零的區塊,或因為 Exchange 發生錯誤,並且參考未使用的頁面,為 「 使用中 」。

無法從先前的錯誤分辨出頁面是否尚未初始化,或在其他的狀態。您必須使用 Esefile 和 Eseutil 進一步檢查的網頁。在這個範例中,頁數是 408 十進位 (衍生自 0x199)。

您可以使用 Eseutil 進一步檢查的網頁。PgnoThis值應該符合的查詢時,頁碼和ulChecksumParity值報告其他* * 計算的總和檢查碼值如果在頁面上的總和檢查碼錯誤。您可以使用 Esefile /D參數來查看使用未經處理的頁面,以判斷是否為未初始化 (全部為 0x00 字元)。

False-1018年錯誤

當磁碟上的頁面是正確的但 I/O 系統會不正確地擷取資料時,就會發生"false"-1018年錯誤。這種錯誤通常是暫時性的並且難以隔離。但即使"false"-1018年錯誤還是需要特別注意。存放裝置] 系統的可靠性仍然受到危害,並且系統可能會發生其他問題或失敗。

如果您懷疑暫時性讀取您的系統中的錯誤,請使用 Esefile /D切換控制或Eseutil /M /P若要確認牽涉到的個別網頁。如果您使用其中一個公用程式來掃描整個資料庫時,請將可能會導致更多的誤判 I/O 系統上的負擔。

Exchange Server 5.5 Service Pack 2 (SP2) 加入功能,以協助您識別暫時性的讀取的錯誤。Exchange 重新讀取到某個頁面 16 次讀取的驗證失敗後。如果嘗試幾次後,成功最後讀取的頁面,則表示讀取可靠性的磁碟是系統問題。即使全部 16 次讀取失敗,它並未明確地保證資料頁就是不正確。執行 Eseutil Esefile 與次要的測試。

資料庫清空

資料庫清空被用來遮蔽 Exchange 資料庫中已刪除的資訊,使它無法復原或由直接檢查資料庫檔案的讀取。 如需有關資料庫清空的詳細資訊,請按一下下面的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
223161 有關 ESE 清空
如果已啟用資料庫清空,空白或部分空白頁的區段可能會覆寫以特定字元模式,但是頁面仍然不傳回未初始化的狀態。

屬性

文章編號: 314917 - 上次校閱: 2014年2月9日 - 版次: 1.0
這篇文章中的資訊適用於:
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
關鍵字:?
kbinfo kbmt KB314917 KbMtzh
機器翻譯
請注意--重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,且可能由 Microsoft Community 利用 Community Translation Framework技術或人工進行事後編修。翻譯過程並無專業譯者參與。Microsoft 同時提供使用者人為翻譯、機器翻譯及社群編修後的機器翻譯三種版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,所有翻譯文章都可能不盡完美,內容都可能出現詞彙、語意或文法上的錯誤。就翻譯內容之不正確或錯誤,或客戶因使用翻譯內容所產生的任何損害,微軟不負擔任何責任。Microsoft將依合理的商業努力不斷地更新機器翻譯軟體和工具,以期能為使用者提供更好的服務。
按一下這裡查看此文章的英文版本:314917
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com