現在オフラインです。再接続するためにインターネットの接続を待っています

[XADM] ESEUTIL /P コマンドまたは EDBUTIL /D /R コマンドの実行が及ぼす影響

概要
Priv.edb、Pub.edb、Dir.edb などの Exchange Server データベース ファイルに対して eseutil /p コマンドまたは edbutil /d /r コマンドを実行すると、徹底的な修復 (以下、ハード リペア) が行われます。この修復では、データベース全体を検証して、データベース内の重要な構造 (システム テーブル、添付ファイル テーブルなど) の確認および修復を行い、また、データベース内の損傷したページの確認も行われます。

修復によって、損傷しているページが見つかると (Jet 以外で行われたページに対する変更によって生じた無効なチェックサムなど)、そのページは削除されます (-1018)。これが発生すると、修復完了後に重要なデータが失われる場合があります。失われるデータの中には、電子メール メッセージの一部、予定表の予定、メモ、添付ファイル、また最悪の場合はシステム テーブルの一部が含まれる場合があります。

そのシステム テーブルが添付ファイル テーブルである場合、サーバー上のすべてのユーザーのメッセージから添付ファイルが失われることがあります。これは 1 つの可能性でしかありませんが、データベース内に損傷したページがある場合、ハード リペア後にデータが失われます。

重要 : 可能な限り、復元はバックアップから行います。

バックアップから復元すると、良質でクリーンな、安定したデータベースをサーバー上で起動し、実行させることができます。ほとんどすべての状況で、データベースにハード リペアを行うよりも、バックアップから復元したほうが、速度も信頼性も高くなります。これは、修復が毎時およそ 4 ~ 6 GB の速度で実行され、さらにその修復後に毎時およそ 3 ~ 6 GB で実行される Isinteg プロセスを実行する必要があるためです (これらの速度は平均値です。データベース上での修復に必要な引き渡しの数と、ハードウェアの速度によって、パフォーマンスが異なる場合があります)。

たとえば、最大限の速さのハードウェア設定を使用する場合、50 GB のデータベースには、修復におよそ 8 時間、Isinteg プロセスにおよそ 8 時間、計 16 時間が必要です。典型的な Wide SCSI に接続した DLT (digital linear tape) 35/70 を使用した場合は、復元の平均速度が毎秒 3 MB ほどであり、同じデータベースの復元に必要な時間はおよそ 5 時間です。つまり、11 時間の節約ということになります。EMC Corporation のシステムなど、非常に高速な "スナップショット" タイプのバックアップ システムでは、このサイズのデータベースをほんの数分で復元できます。

バックアップがなく、データベース上でハード リペアを行う以外の方法がない場合は、ハード リペアを実行後に Isinteg ユーティリティを実行する必要があります。Isinteg ユーティリティでは、ハード リペアを実行したときに発生する可能性のある論理的な問題を修復できます。
  • Exchange Server 4.0 および 5.0 のプライベート インフォメーション ストアの場合は、次のコマンドを実行します。
    isinteg -fix -pri
  • Exchange Server 4.0 および 5.0 のパブリック インフォメーション ストアの場合は、次のコマンドを実行します。
    isinteg -fix -pub
  • Exchange Server 5.5 のプライベート インフォメーション ストアの場合は、次のコマンドを実行します。
    isinteg -pri -fix -test alltests
  • Exchange Server 5.5 のパブリック インフォメーション ストアの場合は、次のコマンドを実行します。
    isinteg -pub -fix -test alltests
Priv.edb データベースまたは Pub.edb データベースで eseutil /p コマンドまたは edbutil /d /r コマンドを実行した後に、データベースに次の現象が発生する場合があります。
  • インフォメーション ストアが停止しなくなる、または応答を停止します。
  • インフォメーション ストアで、メッセージ転送エージェント (MTA) からのメールを受信しなくなります。
  • 電子メールがユーザーの送信トレイに残ります。
  • Store.exe プログラム実行時に、CPU 使用率が非常に高くなり、サーバー上の負荷がなくなります。
  • 高負荷の場合に、Store.exe プログラムでアクセス違反が発生します。
  • ユーザーが電子メールの添付ファイルまたは電子メール メッセージを開けません。
損傷の激しいデータベースでハード リペアを実行すると、データベースは本番の運用に適さなくなります。データベースにハード リペアを行うのは最後の手段としてのみ実行し、可能であれば、常にバックアップから復元します。

マイクロソフトでは、本番で使用するデータベースにハード リペアを実行する必要がある場合は、修復したデータベースから新しいデータベースへデータを移動することをお勧めします。次の 2 つのうちいずれかの方法を使用して、データを新しいデータベースへ移動します。
  • オフライン最適化を使用する : オフライン最適化を実行すると、新しいデータベース構造が自動的に作成され、既存のデータがその構造に移動されます。関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    192185 XADM: How to Defragment with the Eseutil Utility (Eseutil.exe)
    192185 [XADM] Eseutil ユーティリティ (Eseutil.exe) で最適化を行う方法
  • Exmerge を使用する : Exmerge ユーティリティでは、データベースからデータを抽出し、事前に作成済みの別のデータベースに移動できます。関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    259688 XADM: How to Use the Exmerge Utility to Extract Data from a Damaged Private Information Store
詳細
データベースに対してハード リペアが実行されたことがあるか判断するには、次のコマンド ラインを使用してヘッダーをダンプします (データベースが修復されていない場合は、修復カウント (Repair Count) がゼロになります)。
eseutil /mh x:\exchsrvr\mdbdata\priv.edb |more

eseutil /mh x:\exchsrvr\mdbdata\pub.edb |more
以下は、Priv.edb ヘッダーのサンプルです。
Microsoft(R) Windows NT(TM) Server Database Utilities
Version 5.5
Copyright (C) Microsoft Corporation 1991-1999. All Rights Reserved.

Initiating FILE DUMP mode...
Database: d:\exchsrvr\mdbdata\priv.edb

Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,2
Engine ulVersion: 0x620,2
DB Signature: Create time:4/5/2000 17:48:52 Rand:769046 Computer:
cbDbPage: 4096
dbtime: 556457
State: Consistent
Shadowed: Yes
Last Objid: 184
Scrub Dbtime: 0
Scrub Date: 00/00/1900 00:00:00
Repair Count: 1
Repair Date: 2/20/2000 10:48:50
関連情報
この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 259851 (最終更新日 2003-05-14) を基に作成したものです。
-1018 -1019
プロパティ

文書番号:259851 - 最終更新日: 07/30/2003 08:59:00 - リビジョン: 1.0

  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
  • kbinfo KB259851
フィードバック