Exchange ストアの ESEUTIL デフラグでは、整合性チェック/修復も実行されますか?

Exchange ストアの ESEUTIL デフラグでは、整合性チェック/修復も実行されますか?

今朝早く、store.exe が何らかの理由で不調になり、Exchange サーバーを再起動する必要がありました。エラーや問題もなくオンラインに戻り、すべてのトランザクション ログが正常に再生され、すべてのストアが通常どおりマウントされました。私にとっては、これはランダム クラッシュの 1 つに過ぎませんでしたが、コンサルタントは、ストアの 1 つが破損したためではないかと考えています。コンサルタントは私よりもはるかに経験豊富であるため、正しいのかもしれませんが、それは問題ではありません。

疑わしいエラーを修正するために、彼は ESEUTIL デフラグ (PerfectDisk 経由) を実行してエラーを修正する予定であり、これにより存在するエラーも修正されると主張しています。

私の理解では、デフラグ、検証、修復は 3 つの別々のアクションであり、デフラグはいかなる種類の整合性チェックも意味しません。これは正しいですか? 破損している可能性のあるデータベースで直接デフラグを実行すると危険はありますか?

編集:

これはイベント ログの最初のエラーです。これは、発生していた問題の開始を示しています。これが何を示しているかご存知の方はいらっしゃいますか?

Event Type: Error
Event Source:   Microsoft Exchange Server
Event Category: None
Event ID:   1000
Date:       11/23/2011
Time:       8:15:47 AM
User:       N/A
Computer:   SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00   A.p.p.l.
0008: 69 00 63 00 61 00 74 00   i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00   i.o.n. .
0018: 46 00 61 00 69 00 6c 00   F.a.i.l.
0020: 75 00 72 00 65 00 20 00   u.r.e. .
0028: 20 00 65 00 78 00 73 00    .e.x.s.
0030: 70 00 2e 00 64 00 6c 00   p...d.l.
0038: 6c 00 20 00 36 00 2e 00   l. .6...
0040: 35 00 2e 00 37 00 36 00   5...7.6.
0048: 33 00 38 00 2e 00 31 00   3.8...1.
0050: 20 00 34 00 33 00 30 00    .4.3.0.
0058: 65 00 37 00 33 00 35 00   e.7.3.5.
0060: 62 00 20 00 69 00 6e 00   b. .i.n.
0068: 20 00 6b 00 65 00 72 00    .k.e.r.
0070: 6e 00 65 00 6c 00 33 00   n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00   2...d.l.
0080: 6c 00 20 00 35 00 2e 00   l. .5...
0088: 32 00 2e 00 33 00 37 00   2...3.7.
0090: 39 00 30 00 2e 00 34 00   9.0...4.
0098: 34 00 38 00 30 00 20 00   4.8.0. .
00a0: 34 00 39 00 63 00 35 00   4.9.c.5.
00a8: 31 00 66 00 30 00 61 00   1.f.0.a.
00b0: 20 00 66 00 44 00 65 00    .f.D.e.
00b8: 62 00 75 00 67 00 20 00   b.u.g. .
00c0: 30 00 20 00 61 00 74 00   0. .a.t.
00c8: 20 00 6f 00 66 00 66 00    .o.f.f.
00d0: 73 00 65 00 74 00 20 00   s.e.t. .
00d8: 30 00 30 00 30 00 30 00   0.0.0.0.
00e0: 62 00 65 00 66 00 37 00   b.e.f.7.
00e8: 0d 00 0a 00               ....    

答え1

オフライン デフラグは、eseutilデータベース内でページ レベルの破損が検出されると失敗します。破損したページを破棄するには、オプション (rePair) を使用する必要があります/p

論理レベルでのデータの破損(データベースの「構造」ではなく、データベース内の「データ」への損傷と考えてください)は、 では修復できませんeseutil。このisintegツールは、Exchange 2007 までのバージョンのデータベース内の論理的な不整合を見つけることができます。Exchange 2010 では、isintegコマンドnew-MailboxRepairRequestレット (詳細はExchangeチームのブログをご覧ください。)。

とはいえ、コンサルタントのアドバイスについては心配です。ESE または Exchange 関連サービスからのアプリケーション イベント ログに、データベースの破損を示すイベントが表示されていますか? 一般に、Exchange は「ランダムにクラッシュ」することはなく、Exchange の問題よりもハードウェア ドライバーまたはハードウェア自体の問題の方が原因である可能性が高いようです。さらに、ログは問題なく再生されたので、ページ レベルの破損が発生している可能性は低いと思います。

最後に、ページ レベルの破損が発生した場合、その破損をクリーンアップするだけでは解決にはなりません。破損の原因となっている根本原因 (ハードウェアの障害など) を見つけて、それを排除する必要があります。それ以外のことを行うと、リスクにさらされ続けることになります。

オフライン デフラグは、それ自体では大きなリスクではありません。オフライン デフラグが完了したら、以前の増分バックアップと差分バックアップをすべて復元できないため (新しいデータベースは、まったく新しいデータベースであるため)、すぐに完全バックアップを取る必要があります。当然、デフラグ中は、ユーザーはサーバーにアクセスできなくなります。

私は、お金をかけて「修正」を始める前に、今朝何が起こったのかを詳しく調査し、根本的な原因の結論(または少なくとも非常に可能性の高い仮説)を導き出します。

最近、Exchange Server 2003 マシンが VSS スナップショットを取得できず、バックアップの試行中にさまざまな JET エラーが報告されるというケースがありました。別のマシンで新しい Exchange インストールを起動し、すべてのユーザー メールボックスを新しいマシンに移動し、元のサーバー上の問題のあるデータベースを削除して新しいデータベースを作成できるようにすることにしました。ストレス テストをいくつか実行し、元のサーバーが正常に機能していることを確認した後、すべてのメールボックスを元に戻しました。説明されている状況では、この戦略の方が望ましいと思います (元の Exchange Server コンピューターのメールボックス データベースに実際に「破損」があることを示す十分なイベント ログ メッセージがある場合)。

編集:

上記で投稿したエントリは、Microsoft Search の Exchange プロバイダー (Exchange データベースの全文インデックスを作成する) の障害です。その後に何が起こったのか、また、システム イベント ログからこのイベントの直前のイベントを詳しく知りたいです。サーバー コンピューターのボリュームのいずれかでディスク領域不足の状態が発生しましたか?

答え2

ESEUTIL デフラグは、大規模な Exchange データベースの修復専用のものではありません。デフラグ機能は、データベース内の空き領域を再利用し、新しい圧縮されたデータベース ファイルを作成することでデータベースのパフォーマンスを最適化することです。

デフラグの実行中に、不整合や問題が見つかった場合は、データベースに対して特定の修復を実行することもあります。これは全体的なデフラグ プロセスの一部であり、軽微な問題を修正できます。

Exchange Server データベースが破損している場合は、まず ESEUTIL /mh コマンドを実行して、データベースの完全な状態を確認することをお勧めします。データベースがダーティ状態であることがわかったら、データベースの損傷に応じて ESEUTIL /P コマンドまたは ESEUTIL /R コマンドを使用できます。修復操作を試みる前に、データベースのバックアップを必ず作成してください。

適切な回復手順を確実に実行するために、Microsoft サポートに相談することを勧めました。

以下の Microsoft の記事を参照してください。

https://techcommunity.microsoft.com/t5/exchange-team-blog/repairing-exchange-databases-with-eseutil-when-and-how/ba-p/610276

https://social.technet.microsoft.com/wiki/contents/articles/53450.how-to-check-exchange-database-health.aspx

関連情報