Exchange Server エラー -1018
損傷した Exchange データベースを Microsoft IT が復旧する方法
トピック
 | 要約 |
| はじめに |
| エラー -1018 について |
| Microsoft IT がエラー -1018 に対応する方法 |
| -1018 エラーからの回復 |
| ベスト プラクティス |
| まとめ |
| 詳細情報 |
| 付録 A: ケース スタディ |
| 付録 B: -1018 レコードの保持 |
要約
エラー -1018 (JET_errReadVerifyFailure) は、Microsoft® Exchange Server でよく発生する難しいエラーです。このエラーは、基礎となるファイル システムまたはハードウェアの障害や問題により、Exchange データベース ファイルが損傷したことを示します。
この記事では、エラー -1018 が発生する条件について説明します。また、Exchange がデータベース ファイルの損傷を検出し、復旧するために使用する検出メカニズムについても説明します。
Microsoft Information Technology グループ (Microsoft IT) は、世界で最も大規模な Exchange Server 組織の 1 つを運営しています。Microsoft の Exchange 管理者は、これまでいくつもの -1018 エラーの問題を調査し、解決してきました。この記事では、Microsoft IT がこのエラーをどのように監視するか、データベース ファイルの損傷が検出された後に何が起きるか、また問題の影響を受けたデータベースを Microsoft がどのように復旧するかについて説明します。
注 : セキュリティ上の理由から、この記事のフォレスト、ドメイン、内部リソース、組織のサンプル名、および内部で開発されたセキュリティ ファイル名は、Microsoft 社内で使用されている実際のリソース名ではなく、説明の目的でのみ使用しています。
この記事では、Exchange の管理とデータベース アーキテクチャの基礎をよく理解している読者を対象としています。この記事では、エラー -1018 を効果的に処理するための Microsoft IT の経験と推奨事項について説明します。手順説明のガイドを提供することは目的としていません。各企業環境には独自の状況があるため、各組織のニーズに合わせて資料を変更する必要があります。
ここでは Exchange Server 2003 に注目しますが、扱っているほぼすべての資料は任意のバージョンの Exchange に適用できます。Exchange Server 2003 は、-1018 エラーから回復するための重要な新機能を実装しています。これについては、この文書の「Exchange Server 2003 SP1 での ECC によるページ修正」で説明します。
はじめに
完璧なコンピュータ データ ストレージ メカニズムは存在しません。ディスクやテープは劣化し、ハードウェアの故障やファームウェアのバグは、データの破損の原因となることがあります。この現実に対処するための最も基本的な戦略は冗長性を実現することです。たとえば、ディスクをミラー化したり、複製したりできます。また、プライマリ ストレージが危険な状態になったとき (危険な場合、ではありません) にデータを別のコピーから復旧できるように、データがリモートの場所にバックアップされます。
データが破損したときのリスクは、データの損失のみではありません。データが破損し、それが検出されていない場合でも、その破損したデータに基づいて不正な決定が行われる場合があります。データベース レコードのランダムな破損によって小数点が削除された結果、だれかが一時的に億万長者になったという話は報道でときどき耳にします。データベースの破損は、より気付きにくいエラーやさらに難しいエラーの原因になることがあります。Exchange では、破損したメタデータに基づいて操作が行われると、あるユーザーに宛てたメールが別のユーザーに送信されたり、データベース内のすべてのメールが失われたりすることがあります。
このため Exchange データベースでは、このような損傷を検出する機能を実装しています。ランダムな破損の検出よりもはるかに重要なことは、その破損部分に基づいて操作を行わないことです。Exchange がデータベースの損傷を検出した後、損傷した領域は読み取りがまったく不可能な領域として処理されます。そのため、破損したデータを信用したことによってデータベースの損害が拡大することはありません。
エラー コード -1018 は、基礎となるプラットフォームの問題によるデータのランダムな破損を Exchange が検出したときにレポートされます。データの破損は深刻な問題ですが、データベースの実行中に -1018 エラーが検出され、データベースの停止や重大な誤作動の原因となることはまれです。それは、Exchange データベースのページの大半にはユーザー メッセージ データが書き込まれているからです。データベース内の任意の単一ページの損失は、たいていの場合にメッセージの消失を引き起こします。これにより、1 人のユーザーまたは 1 つのユーザー グループが影響を受ける可能性はありますが、データベース全体の構造的および論理的な整合性には影響がありません。-1018 の問題が検出された後、Exchange は失われたデータがデータベース全体の整合性に対して重要な問題とならない限り実行を継続します。
-1018 エラーは、データベース内の同じ場所について繰り返しレポートされることがあります。これは、損傷した特定のメッセージにユーザーが繰り返しアクセスしようと試みた場合に発生することがあります。アクセスが失敗するたびに、新しいエラーがログに記録されます。
エラー -1018 に関連付けられているデータの直接的な損失は非常にわずかな場合があるため、エラーを無視したくなることがあります。これは危険な誤りです。-1018 エラーは、徹底的かつ迅速に調査する必要があります。それは、エラー -1018 が、プラットフォームにすぐにも発生し得る他の問題が存在する可能性を示すためです。
エラー -1018 について
エラー コード -1018 (JET_errReadVerifyFailure) は、データベースのページの読み取り時に次の 2 つの条件のどちらかが検出されたことを意味します。
| • | ページに格納されている論理ページ番号が、データベース ファイル内部のページの物理的な場所に一致していない。 |
| • | ページに格納されているチェックサムが、Exchange がページ上に予期するチェックサムと一致していない。 |
統計的に、-1018 エラーは、不正なページ番号よりも不正なチェックサムに関連している可能性がはるかに高くなっています。
これらの条件がデータベースに対するファイル レベルの損傷を示している理由を理解するには、Exchange データベース ファイルがどのように構成されているかをもう少し知る必要があります。
ページ順序
各 Exchange Server 2003 データベースは、.edb ファイルおよび .stm ファイルという 2 つの対応するファイルから構成されています。これらのファイルは、対応する両方のファイルとも、コピー、移動、またはバックアップする必要があり、相互に同期している必要があります。
データベース ファイルの内部では、データは連続した 4 KB (4,096 バイト) の複数のページで編成されています。複数のページをまとめて、バランス ツリー (B+-Tree) という論理構造を形成できます。これらのツリーのいくつかをリンクして、データベース テーブルが形成されます。データベースには、ホストされているメールボックスやフォルダの数に応じて数千のテーブルが存在する場合があります。
各ページは単一の B+-Tree によって所有され、各 B+-Tree は単一のテーブルによって所有されます。エラー -1018 は、個々のページ レベルで損傷をレポートします。データベース テーブルはページから構成されるため、エラーはデータベースの上位の論理レベルの問題も暗黙的に示しています。
各データベース ファイルの先頭には、2 つのヘッダー ページがあります。ヘッダー ページは、データベースに関する重要情報を格納します。Exchange Server Database Utilities ツール の 1 つである Eseutil を使用して、ヘッダー ページに関する情報を表示できます。
データベース ファイルのヘッダー ページの後には、データ ページと、データ取得のため待機している空のページのどちらかがあります。各データ ページには 1 から開始する番号が連続して付けられています。ファイルの先頭には 2 つのヘッダー ページがあるため、3 番目の物理ページがデータベース内の最初の論理データ ページになります (2 つのヘッダー ページは論理ページ -1 および 0 と考えることができます)。
注 : 各データベース ファイル全体で 1 つのヘッダーがあり、データベース内の各ページにそれぞれ固有のヘッダーがあります。2 つのヘッダーは区別が紛らわしい可能性があります。
データベース ヘッダーは、データベース ファイルの先頭にあり、データベース全体に関する情報を格納します。ページ ヘッダーは各ページの最初の 40 バイトであり、そのページに関する重要情報のみ格納します。Eseutil ではデータベース ヘッダー情報を表示できるのと同様に、ページ ヘッダー フィールドも表示できます。
Exchange データベースでは、データベース ファイルの物理バイト オフセットに対応する論理ページを簡単に計算できます。データベース ヘッダーの最初のコピーである論理ページ -1 は、オフセット 0 から開始します。データベース ヘッダーの 2 番目のコピーである論理ページ 0 は、オフセット 4,096 から開始します。データベースの最初のデータ ページである論理ページ 1 は、オフセット 8,192 から開始します。論理ページ 2 はオフセット 12,228 から開始します。以降も同様です。
各 -1018 エラーはデータベースの単一ページに対するものであり、高度なトラブルシューティングではエラーが発生したページを特定することが役立つ場合があります。
一般的な計算式は次のとおりです。
| • | (論理ページ番号 + 1) × 4,096 = バイト オフセット |
| • | (バイトオフセット ÷ 4,096) - 1 = 論理ページ番号 |
次の例も役立ちます。
データベース内の論理ページ 101 の正確なバイト オフセットを知る必要があるとします。最初の計算式 (101 + 1) × 4,096 = 417,792 を使用すると、論理ページ 101 は厳密にファイルの 417,792 バイト目から開始することがわかります。
次に、バイト オフセット 4,104,192 にあるページを知る必要があるとします。2 番目の式 (4,104,192 ÷ 4,096) - 1 = 1,001 を使用すると、論理ページ 1,001 がファイルの 4,104,192 バイト目から開始することがわかります。
ほとんどの場合、Windows アプリケーション ログ イベント レポート エラー -1018 は、不良ページの場所をバイト オフセットとして示します。したがって、おそらく 2 番目の計算式が最も頻繁に使用されます。どのような場合も、2 つの計算式を使用して、必要に応じて論理ページとバイト オフセット間を変換できます。
論理ページ番号は、実際にはデータベースの各ページに記録されています (Service Pack 1 (SP1) を適用した Exchange Server 2003 では、これを行う方法が変更されています。詳細については、この記事の「Exchange Server 2003 SP1 での ECC によるページ修正」を参照してください)。Exchange はページを読み取る場合に、論理ページ番号がバイト オフセットと一致するかどうかをチェックします。一致しない場合は -1018 エラーとなり、ページは読み取り不可能として処理されます。
物理ページと論理ページ間の対応により、Exchange はページがデータベース ファイル内に正しい順序で格納されているかどうかを検出できるため、この対応は重要です。物理的な場所が論理ページ番号と一致しない場合、ページはファイル システムの間違った場所に書き込まれています。ページ上のデータが正しい場合でも、ページが不正な場所にある場合、Exchange は問題を検出し、ページを使用しません。
ページ チェックサム
論理ページ番号と共に、データベース内の各ページにはそのデータに対して計算されたチェックサムも格納されます。チェックサムはページの先頭にあり、ページ上のデータに対してアルゴリズムを実行することで生成されます。このアルゴリズムは、4 バイトのチェックサム番号を返します。ページ上で何かが変化した場合、ページ上のチェックサムはページ上のデータと一致しなくなります (次の節で説明するように、Exchange Server 2003 SP1 では、チェックサム アルゴリズムがこれよりも複雑になっています)。
Exchange は、データベース内のページを読み取るたびに、チェックサム アルゴリズムを再実行し、その結果がページ上に既に存在するチェックサムと同じであることを確認します。同じでない場合は、ページ上の何かが変化しています。-1018 エラーがログに記録され、ページは読み取り不可能として処理されます。
Exchange Server 2003 SP1 での ECC によるページ修正
Exchange Server 2003 SP1 には、一部の -1018 関連の損傷に対する重要な新しい復旧メカニズムが組み込まれています。このメカニズムは、各ページに配置されているエラー修正コード (ECC) チェックサムです。このチェックサムは、以前のバージョンの Exchange にあったチェックサムの他に追加されています。
現在、各 Exchange ページには 2 つのチェックサムがあり、各ページの先頭に並んでいます。最初のチェックサム (データ整合性チェックサム) は、ページが損傷しているかどうかを判断します。2 番目のチェックサム (ECC チェックサム) を使用すると、一部の種類のランダムな破損を自動的に修正できます。Exchange Server 2003 SP1 より前の Exchange では、損傷を確実に検出できましたが、損傷に対しては何の処理も行うことができませんでした。
多くの -1018 エラー事例を調査することにより、Microsoft では、-1018 エラーの約 40% はビット フリップが原因であることを発見しました。ビット フリップは、ページ上の単一ビットの値が不正だった場合に発生します。つまり、1 が 0 に、または 0 が 1 に変わってしまったビットです。これは、コンピュータ ディスクとメモリでよく発生するエラーです。
ECC チェックサムではビット フリップを修正できます。このため、Exchange Server 2003 SP1 以上を使用している場合は、-1018 エラーの約 40% が自動修正されます。
注 : ECC チェックサムは複数ビットのビット フリップを検出することは可能ですが、実装するのは実際的でありません。単一ビットのエラー修正に必要なパフォーマンス オーバーヘッドはわずかですが、複数ビットのエラーを検出して修正するのはパフォーマンスの点でコストが高くなります。統計的に見ると、ページ エラーの分布は、単一ビット エラーおよびページに対する大規模な損傷という両極端に集中する傾向があります。
-1018 エラーが ECC メカニズムによって修正された場合、エラーを無視しても安全であることを意味しているわけではありません。ECC による修正を行っても、基礎となるプラットフォームがデータを確実に格納または取得しなかったという事実は変わりません。ECC は、エラー -1018 からの復旧を自動化しますが (現時点で 40%)、-1018 エラーに対応する方法は何ら変わりません。
ECC チェックサムの導入に伴い、Exchange データベースのページ ヘッダーの形式は変更される必要がありました。論理ページ番号の格納に使用されていた各ページ ヘッダーのフィールドは、ECC チェックサムと合わせたページ番号を格納するようになりました。このため、Exchange Server 2003 SP1 データベースは下位互換性がなく、Exchange Server 2003 のオリジナル リリースとの互換性さえありません。同じことが、Eseutil などのデータベース ツールにも適用されます。古いバージョンのツールを使用すると、ECC チェックサムが考慮されないため、ECC データベースが大規模に破損しているように見えます。
ECC によるページ修正の詳細については、マイクロソフト サポート技術情報の記事でExchange Server 2003 SP1 の新機能のエラー訂正コード (ECC) に関するページを参照してください。
バックアップとエラー -1018
-1018 エラーは、データベースの実行中にいつでも発生する可能性があります。ただし、-1018 の問題の大多数は、実際にはこのように検出されるのではありません。むしろバックアップ中に検出されることの方が多いのです。
-1018 エラーは、ページの読み取り時にのみレポートされますが、データベース内のすべてのページが頻繁に読み取られるわけではありません。たとえば、ユーザーの [削除済みアイテム] フォルダ内のメッセージに長期間アクセスしない場合があります。このような場所にある -1018 エラーは、長期間検出されない可能性があります。-1018 の問題を迅速に検出するには、データベース内のすべてのページを読み取る必要があります。データベース全体をバックアップするにはデータベース全体を読み取る必要があるため、オンライン バックアップでは、データベース全体で -1018 の損傷をチェックする機会がおのずと生じます。
Exchange オンライン ストリーミング API によるバックアップ
Exchange では、オンライン ストリーミング バックアップ アプリケーション プログラミング インターフェイス (API) を常にサポートしてきました。この API により、Exchange データベースを実行中にバックアップできます。多くのサード パーティ ベンダが、この API を使用する Exchange 対応のバックアップ モジュールまたはエージェントを作成してきました。Microsoft Windows Server™ 2003 または Windows® 2000 Server に付属するバックアップ プログラムである Backup では、Exchange ストリーミング バックアップ API がサポートされます。Exchange Server または Exchange 管理者プログラムをコンピュータにインストールした場合、Backup は Exchange 対応のオンライン バックアップに対して動的に有効になります。
-1018 ページがオンライン バックアップ中に検出された場合は、バックアップが停止します。Exchange では、-1018 の損傷のあるデータベースのオンライン バックアップの完了を許可しません。このため、バックアップに -1018 の問題が含まれることはありません。これにより、最後のバックアップから復元し、データベースをその後のトランザクション ログ ファイルで最新の状態にして -1018 の問題から復旧できるため、バックアップに -1018 の問題が含まれていないことは重要です。この処理を行うと、データ損失と -1018 ページを含まない最新のデータベースが生成されます。
トランザクション ログの再生で -1018 エラーがデータベースに取り込まれることはありません。ただし、トランザクション ログの再生で、既に存在する -1018 エラーが明らかになることがあります。トランザクション ログ データを適用するには、Exchange がデータベース内の各適用先ページを読み取る必要があります。適用先ページが損傷している場合、トランザクション ログの再生は失敗します。トランザクション ログによる更新がページの一部についてのみ実行される場合があるため、Exchange はトランザクション ログの内容でページを置換できません。
オンライン バックアップから復元し、トランザクション ログの再生中に -1018 エラーが発生した場合、最も可能性の高い理由は、復元中または復元後にハードウェアの不安定性によりデータベースが破損したことです。これをテストするには、正常であることがわかっているハードウェアに同じバックアップを復元します。詳細については、この記事の「Exchange が -1018 エラーの原因となることがあるか」を参照してください。
オンライン バックアップからの復元とその後のトランザクション ログの再生は、-1018 エラーから回復するための標準的な戦略です。特殊な状況でのその他の戦略については、この記事の「-1018 エラーからの回復」で概説しています。
バックアップの再試行と一時的な -1018 エラー
すべての -1018 エラーが永続的なものであるとは限りません。-1018 エラーは、メモリの問題またはディスク以外のサブシステムの問題が原因でレポートされる場合があります。たとえば、ディスク上のデータベース ページは正常でも、システムがディスクを確実には読み取らない場合があります。このようなケースを処理し、問題のあるハードウェアでもバックアップが成功する可能性を高めるために、Exchange には、バックアップ中に発生した -1018 エラーを再試行する機能があります。
ページのバックアップ中に -1018 エラーがレポートされた場合、Exchange は 1 〜 2 秒待機してから、ページの読み取りを再試行します。この操作を最大 16 回行ってから Exchange は中止し、ページの読み取りとバックアップが失敗します。
Exchange が最終的にページを正常に読み取った場合でも、ディスク上のページのコピーは正常ですが、システムの他の場所に重大な問題が発生している場合があります。Exchange がページの読み取りに成功しなかった場合でも、ページが不良であることの最終的な証明にはなりません。ハードウェア キャッシュの実装方法によっては、16 回の読み取り試行がディスクから直接行われず、同じキャッシュで行われている可能性があります。Exchange は、各読み取り試行の間に待機してからディスクからの直接読み取りを再試行し、読み取りがキャッシュから行われない可能性を高めます。
Exchange ボリューム シャドウ コピー サービス API のオンライン バックアップ
Exchange Server 2003 を Windows Server 2003 で実行している場合は、Exchange のボリューム シャドウ コピー サービスベースのオンライン バックアップを実行する追加のオンライン バックアップ オプションがあります。ボリューム シャドウ コピー サービス オンライン バックアップ API は、ストリーミング バックアップ API と似た機能を持つ新しい手法ですが、データベース ファイル サイズによらず復元時間を高速化できます。ボリューム シャドウ コピー サービス バックアップがストリーミング バックアップと比べてどの程度高速であるかは、いくつかの要因に依存します。最も重要な要因は、ボリューム シャドウ コピー プロバイダがソフトウェアベースとハードウェアベースのどちらであるかということです。ソフトウェアベースとハードウェアベースのどちらのプロバイダも、ファイルがロックされて開かれ、使用中の場合でも、スナップショットの作成とファイルのコピーの複製を行うことができます。ただし、ソフトウェア プロバイダを使用している場合、プロセスは通常のファイル コピーを作成する場合ほど高速ではありません。非常に大きなファイルに対してもスナップショットまたは複製プロセスをほぼ瞬時に行うには、ハードウェア プロバイダを使用する必要があります。
Windows 2003 の Backup には、ソフトウェアベースの汎用ボリューム シャドウ コピー サービス プロバイダが含まれていますが、Exchange 対応のボリューム シャドウ コピー サービス バックアップはサポートされていません。Windows のいずれかのバージョンの Backup を Exchange バックアップ アプリケーションとして使用している場合は、ストリーミング API オンライン バックアップを実行する必要があります。
Exchange 対応のボリューム シャドウ コピー サービス バックアップは、20 秒以内に完了する必要があります。それは、バックアップ中は Exchange がデータベース ファイルへの変更を停止するからです。スナップショットまたは複製が 20 秒以内に完了しない場合、バックアップは失敗します。したがって、バックアップは非常に高速に完了する必要があるため、ハードウェア プロバイダが必要となります。
Exchange には、ボリューム シャドウ コピー サービス バックアップ中にデータベース ページを読み取る機会がありません。このため、データベースはバックアップ中に -1018 の問題をチェックできません。ボリューム シャドウ コピー サービスベースの Exchange バックアップ ソリューションを使用する場合、ベンダはバックアップの完了後すぐに別の操作でバックアップの整合性を確認する必要があります。
ボリューム シャドウ コピー サービス バックアップと Exchange の詳細については、マイクロソフト サポート技術情報の記事「Exchange Server 2003 のデータ バックアップとボリューム シャドウ コピー サービス」を参照してください。
アプリケーション ログのイベント ID
-1018 エラーが発生した場合、アプリケーション ログに -1018 イベントはありません。代わりに、[説明] フィールドの一部として -1018 をレポートする複数の異なるイベントがあります。どのイベントがログに記録されるかは、-1018 の問題が検出された状況によって異なります。
-1018 エラーに関連付けられているこのイベント一覧は包括的ではありませんが、監視する必要のあるコア イベントが含まれています。
Exchange のすべてのバージョンについて、Microsoft Operations Manager (MOM) はイベント ソース Extensible Storage Engine (ESE) からのイベント 474、475、および 476 を監視します。Exchange Server 2003 SP1 を実行している場合は、イベント 399 が監視されていることを確認する必要もあります。
イベント 474
Exchange Server 2003 SP1 より前の Exchange バージョンでは、イベント 474 はチェックサムの不一致が検出されたときにログに記録されます。Exchange Server 2003 SP1 では、このイベントは複数ビット エラーがページに存在する場合のみログに記録されます。単一ビット エラーが検出された場合は、イベント 399 (この記事で後述します) が代わりに記録されます。
典型的なイベント 474 の例を次に示します。
イベントの種類 : エラー
イベント ソース : ESE
イベント ID: 474
説明 : インフォメーション ストア (3500) 最初のストレージ グループ : ページのチェックサムが一致しないため、ファイル "C:\mdbdata\priv1.edb" のオフセット 2121728 (0x0000000000206000) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。予期されたチェックサムは 1848886333 (0x6e33c43d) ですが、実際のチェックサムは 1848886845 (0x6e33c63d) でした。読み取り処理は、エラー -1018 (0xfffffc06) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
このイベントの [説明] フィールドには、高度なトラブルシューティングと分析に使用できる情報が表示されます。-1018 エラーがレポートされた後に、この情報を必ず保存する必要があります。この情報をハードウェア ベンダまたは Microsoft 製品サポート サービスに提供すると、複数の -1018 エラーのトラブルシューティングに役立つ場合があります。
[説明] フィールドには、どのデータベースのどの場所で損傷が発生したかが示されます。バイト オフセットから論理ページ番号への変換については、この記事の「ページ順序」で説明した計算式を思い出してください。この計算式を使用すると、(2121728 ÷ 4096) -1 = 517 となるため、このエラーで損傷したページが論理ページ 517 であることがわかります。ページの直接分析により、損傷の原因となった問題をハードウェア ベンダが判断するのに役立つパターンが示されることがあります。
説明には、予期されるチェックサムとしてページに書き込まれているチェックサム (6e33c43d) も示されます。実際のチェックサムは、Exchange がページの読み取り時に再計算したチェックサム (6e33c63d) です。
チェックサム値が何であるかを知るのが役立つのはなぜでしょう。チェックサムの差異のパターンは、高度なトラブルシューティングに役立つ場合があります。この例として、この記事の「付録 A: ケース スタディ」を参照してください。
また、予期されたチェックサムと実際のチェックサムを比較することで、特定の -1018 エラーが単一ビット エラー (ビット フリップ) の結果であるかどうかがわかります。この比較を行うには、チェックサムを等価なバイナリ数値に変換します。チェックサムが単一ビットを除いて同一である場合、ページ上のエラーはビット フリップが原因です。
前の例に示したチェックサムは、科学計算モードで Calc.exe を使用して、等価なバイナリに変換できます。
0x6e33c43d = 1101110001100111100010000111101
0x6e33c63d = 1101110001100111100011000111101
Single bit difference ^ (単一ビットの相違)
前の例では、このエラーが Exchange Server 2003 SP1 データベースで発生した場合、エラーは自動的に修正されます。
Exchange Server 2003 SP1 では、イベント 474 の [説明] フィールドでレポートされるチェックサムは、ページ整合性チェックサムと ECC チェックサムを一緒に示します。次に例を示します。
説明 : インフォメーション ストア (3000) SG1018: ページのチェックサムが一致しないため、ファイル "D:\exchsrvr\SG1018\priv1.edb" のオフセット 2371584 (0x0000000000243000) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。予期されたチェックサムは 2484937984258 (0x0000024291d88902) ですが、実際のチェックサムは 62488400759392765 (0x00de00de91d889fd) でした。読み取り処理は、エラー -1018 (0xfffffc06) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
ここに示されているチェックサムは 16 桁の 16 進文字であり、前の例ではチェックサムは 8 桁の 16 進文字であることに注意してください。新しいチェックサム形式では、最初の 8 文字が ECC チェックサムで、最後の 8 文字がページ整合性チェックサムです。
イベント 475
イベント 475 は、不正なページ番号を原因とする -1018 の問題を示しています。このイベントは、Exchange Server 2003 では使用されなくなりました。代わりに、不正なチェックサムと不良ページ番号がイベント 474 で一緒にレポートされます。次に、イベント 475 の例を示します。
イベント タイプ : エラー
イベント ソース : ESE
イベント ID: 475
説明 : インフォメーション ストア (1448) ページ番号が一致しないため、ファイル "C:\MDBDATA\priv1.edb" のオフセット 1257906176 (0x000000004afa2000) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。予期されたページ番号は 307105 (0x0004afa1) ですが、実際のページ番号は 307041 (0x0004afe1) でした。読み取り処理は、エラー -1018 (0xfffffc06) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。
イベント 475 は誤解されることがあります。これはページがデータベースの間違った場所にあることを意味しているのではない場合があります。これはページ番号フィールドが間違っていることを意味しているにすぎません。ページ上のチェックサムも有効である場合にのみ、ページが間違った場所にあると結論付けることができます。フィールドが破損しているのか、ページが間違った場所にあるのかを判断するには、実際のページの高度な分析が必要です。ほとんどの場合は、ページ フィールドが破損しています。
前の例では、ページ番号フィールドの違いが単一ビットであるため、このページはおそらく正しい場所にあるが、ビット フリップにより損傷していることを示していることに注意してください。
イベント 476
イベント 476 は、エラー 1019 (JET_PageNotInitialized) を示します。このエラーは、データベース内のページが使用中であると予期されるのにもかかわらず、ページ番号がゼロである場合に発生します。
Exchange 2003 Service Pack 1 より前の Exchange のリリースでは、各ページの最初の 4 バイトにチェックサムが格納され、次の 4 バイトにページ番号が格納されます。ページ番号フィールドがすべてゼロの場合、ページは初期化されていないと見なされます。Exchange 2003 Service Pack 1 で ECC チェックサムの場所を作るために、ページ番号フィールドは ECC チェックサム フィールドに変換されました。ページ番号は、チェックサム データの一部として計算されるようになり、元のチェックサム フィールドと ECC チェックサム フィールドの両方がゼロの場合はページが初期化されていないと見なされるようになりました。
イベント タイプ : エラー
イベント ソース : ESE
イベント ID: 476
説明 : インフォメーション ストア (3500) 最初のストレージ グループ : データベースにページ データが含まれていないため、ファイル "C:\mdbdata\priv1.edb" のオフセット 2121728 (0x0000000000206000) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。読み取り処理は、エラー 1019 (0xfffffc05) のため失敗します。この状態が続く場合は、以前のバックアップからデータベースを復元してください。これはハードウェアに問題がある可能性があります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
たいていの場合、エラー 1019 はエラー -1018 の単なる特殊ケースです。ただし、データベース内の論理的な問題が原因で、空のページが使用されていることをテーブルが示している場合もあります。データベース全体の高度な論理分析を行わないと、この 2 つのケースを区別できないため、エラー 1019 がエラー -1018 の代わりにレポートされます。
エラー 1019 が発生するのはまれであり、このエラーの分析とトラブルシューティングの詳細な説明はこの記事では扱いません。
イベント 399
イベント 399 は、Exchange Server 2003 SP1 で追加された新しいイベントです。これはエラー イベントではなく警告イベントです。データベースで単一ビットの破損が検出され、修正されたことを示します。
イベント タイプ : 警告
イベント ソース : ESE
イベント ID: 399
説明 : インフォメーション ストア (3000) 最初のストレージ グループ : ファイル "C:\mdbdata\priv1.edb" のオフセット 4980736 (0x00000000004c0000) から 4096 (0x00001000) バイトのデータベース ページの読み取りを確認できませんでした。ビット 144 が壊れていたため、修正しました。これはハードウェアに問題があり、再度発生する可能性があります。このような一時的なエラーは、このファイルを含んでいるストレージ サブシステムに致命的なエラーが発生する前兆を示していることがあります。問題の診断についての詳細はハードウェア製造元に問い合わせてください。
イベント 399 はエラーではなく警告ですが、監視する必要があり、修正できない -1018 エラーと同じぐらい慎重に扱う必要があります。すべての -1018 エラーは、多少なりともプラットフォームが不安定であることを示しており、今後もエラーが発生する可能性があることを示している場合があります。
イベント 217
イベント 217 は、-1018 エラーによりバックアップが失敗したことを示します。
イベント タイプ : エラー
イベント ソース : ESE
イベント ID: 217
説明 : インフォメーション ストア (1224) 最初のストレージ グループ : データベース (ファイル C:\mdbdata\priv1.edb) のバックアップ中に、エラー (-1018) が発生しました。このデータベースを復元することはできません。
このエラーが発生する直前に、通常はアプリケーション ログにすべて同じページに対する 16 個のイベント 474 エラーが記録されています。バックアップ中に、Exchange はページの読み取りを 16 回再試行し、各試行の間に 1 〜 2 秒待機します。バックアップが成功する可能性を高めるために、この処理はエラーが一時的な場合に行われます。
再試行は、通常のランタイム読み取りエラーに対しては行われず、バックアップ中にのみ行われます。通常操作中に再試行を実行すると、頻繁にアクセスされるページが関係する場合にデータベースが停止する可能性があります。
イベント 221
イベント 221 は、バックアップの成功を示します。データベース ファイルのバックアップ時に個々のデータベース ファイルに対して生成されます。
イベント タイプ : 情報
イベント ソース : ESE
イベント ID: 221
説明 : インフォメーション ストア (1224) 最初のストレージ グループ : ファイル C:\mdbdata\priv1.edb のバックアップを終了しています。
----------
イベント タイプ : 情報
イベント ソース : ESE
イベント ID: 221
説明 : インフォメーション ストア (1224) 最初のストレージ グループ : ファイル D:\mdbdata\priv1.stm のバックアップを終了しています。
サードパーティ バックアップ アプリケーションを使用している場合、ここに示したイベントに加えて、監視する必要のある追加のバックアップ イベントが存在する場合があります。
根本的な原因
最も単純なレベルでは、-1018 エラーの根本的な原因は 3 つしかありません。
| • | Exchange データベースの基礎となるプラットフォームが Exchange データをストレージに確実に書き込めなかった。 |
| • | Exchange データベースの基礎となるプラットフォームが Exchange データをストレージから確実に読み取れなかった。 |
| • | Exchange データベースの基礎となるプラットフォームが Exchange データを格納時に確実に保存できなかった。 |
この分析レベルでは、問題の範囲を定義します。実際的なレベルでは、次のことを知る必要があります。
| • | このエラーは再発するか。 |
| • | エラーから回復するにはどうすればよいか。 |
Microsoft IT がエラーの再発の可能性を評価する方法については、この記事の「サーバー評価と根本的な原因の分析」で説明します。復旧戦略についても、この記事で後ほど説明します。ここでは、エラー -1018 の最も一般的な根本原因についてまとめます。
| • | ディスク ドライブの障害 - 単純なドライブ エラーに加えて、Microsoft 製品サポート サービスが、ドライブ エラー発生後に設定された RAID (Redundant Array of Independent Disks) ドライブの再構築に失敗するという事例を扱うことは珍しくありません。 |
| • | ハードの問題 - サーバーまたはディスク サブシステムに対する電力の突然の遮断により、最近変更したデータが破損または消失することがあります。エンタープライズ クラス サーバーおよびストレージ システムは、電力の突然の遮断をデータの破損なしに処理できる必要があります。Microsoft では、テスト サーバーの電源を繰り返し抜くことによる Exchange および Exchange サーバーのテストを何千回も実施しましたが、Exchange データは破損しませんでした。 |
| • | クラスタ フェイルオーバー - アプリケーションが、あるクラスタ ノードから別のクラスタ ノードに移動されると、移動中にディスク I/O が失われたり、正しくキューに入れられなかったりすることがあります。個々のコンポーネントが堅牢で適切に設計されている場合でも、クラスタ システムとして適切に連動しない場合があります。このことは、Microsoft がスタンドアロン コンポーネントの認定プログラムとは別にクラスタ システムの認定プログラムを持っている理由の 1 つです。クラスタ システム認定プログラムは、すべての重要なコンポーネントを別々にではなくまとめてテストします。 |
| • | ディスク サブシステムでのリセットおよびその他のイベント - 企業では、複数のサーバーが共有ストレージ フレームにアクセスするストレージ エリア ネットワーク (SAN) およびその他の集中ストレージ テクノロジを実装することがますます増えています。これらの環境ではディスク リソースの適切な構成と分離が重要であるだけでなく、冗長 I/O パスと、ディスク I/O に関連するフィルタやサービスの増加も管理する必要があります。I/O チェーンの複雑さが増すと、必然的に障害ポイントも増加し、製品の整合性が低下します。 |
| • | ハードウェアまたはファームウェアのバグ - 標準診断テストの実行がこれらの問題の診断に成功することはまれです (標準診断の実行でこの問題を捕捉できるとすれば、既に捕捉済みとなっているはずですが、そうではありません)。これらの問題を理解するには、多くの場合、複数のサーバーからの相関データおよび特殊な診断スイートとストレス テスト設備の使用が必要です。 |
これは、エラー -1018 のすべての原因を網羅しているわけではなく、これらのエラーの大多数を占める問題のカテゴリを概説したものです。
Exchange が -1018 エラーの原因となることがあるか
Exchange が -1018 エラーの根本的な原因となることはあるでしょうか。Exchange は、次の一方または両方を行った場合に、-1018 条件を生成する場合があります。
| • | ページに対して不正なチェックサムを生成した。 |
| • | ページを正しく作成したが、間違った場所にページを書き込むようオペレーティング システムに指示した。 |
チェックサムを生成し、データベース ファイルにページを書き戻す Exchange メカニズムは、最初の Exchange リリース以降安定して稼動している単純なアルゴリズムに基づいています。Exchange Server 2003 SP1 では ECC チェックサムが追加されましたが、ページ整合性チェックサム メカニズムは基本的に変更されませんでした。ECC チェックサムは、元の破損検出チェックサムの隣に新たに配置されたチェックサムです。Exchange データベース ページの整合性は、現在も元のチェックサムを通じて検証されます。
注 : Exchange Server 2003 SP1 より前のバージョンの Exchange の Esefile または Eseutil を使用して Exchange Server 2003 SP1 以降のデータベースのチェックサムを検証した場合は、データベースのほぼすべてのページが損傷しているものとしてレポートされます。ページ形式は Exchange Server 2003 SP1 で変更されたため、以前のツールではページを正しく読み取ることができません。ECC チェックサム ページを検証するには Exchange Server 2003 SP1 より後のツールを使用する必要があります。
ページ整合性チェックサム メカニズムの論理エラーでは、まばらで一見ランダムなページ エラーではなく、大規模で時間的に近接したデータベースの破損がレポートされることがあります。
これは、論理データの破損を引き起こした問題が Exchange に存在しなかったことを意味するわけではありません。ただし、これらの問題は -1018 エラーではなく別のエラーの原因となります。エラー -1018 は、基礎となるプラットフォームが原因で起こる論理的にランダムな破損の検出を目的としています。
誤検出されたかまたは見逃された -1018 レポートの原因が Exchange の問題であるケースがいくつかあります。これらのケースでは、チェックサム メカニズムは正しく動作しますが、エラーをレポートするコード パスに問題がありました。これが原因で、問題がない場合でも -1018 エラーがレポートされたり、レポートされるべきエラーがレポートされなかったりしました。影響を受けたデータベースを検査すると、すぐにこのような問題を解決できます。
Exchange トランザクション ログ ファイルの再生機能も、Exchange の問題が原因の可能性がある -1018 エラーを Microsoft で効果的に診断するための機能です。-1018 の問題がデータベースに存在する場合にはオンライン バックアップを完了できないことを前の節で説明しました。また、バックアップの復元後に、トランザクション ログの再生により、バックアップ後に行われたすべての変更が再作成されます。これにより、正常と確認されているデータベースのコピーから Exchange の開発を開始し、それに対するすべての変更をトレースできます。
Exchange 管理者として、次の 2 つの状況は、-1018 エラーの考えられる原因として Exchange を詳細に調べる必要があることを示しています。
| • | オンライン バックアップの復元後、トランザクション ログ ファイルの再生が開始する前に、復元したデータベース ファイルで -1018 エラーが発生する。これは、チェックサム検証がバックアップ中に正しく動作しなかったことを示している場合があります。バックアップ メディアが不良になったか、問題のあるハードウェアが原因で復元中にデータが損傷した可能性もあります。次のテストでもう少し明確になります。 |
| • | 復元したデータベースのチェックサム検証後、トランザクション ログ再生が正常に完了した後に -1018 エラーが存在する。これは、論理的な問題により不正なチェックサムが生成されたことを示している可能性があります。別のハードウェアでもこの問題が一貫して再現される場合は、ハードウェアの問題によって復元および再生プロセス中にファイルがさらに損傷した可能性を除外できます。 |
反対に、バックアップからの復元とログ ファイルのロール フォワードで -1018 エラーが検出されない場合は、外部的な問題が原因でデータベースが損傷したことを強く示しています。
要するに、エラー -1018 の目的は、次の 2 種類のデータ破損のみレポートすることです。
| • | ページに格納された論理ページ番号がゼロ以外であり、データベース内のページの物理的な位置と一致しない。 |
| • | ページに格納されているチェックサムが、ページに格納されている実際のデータと一致しない。 |
Exchange は、ページ上のデータに対する両方の破損を検出し、データベースのページが間違った場所に書き込まれないように保護します。
Microsoft IT がエラー -1018 に対応する方法
Microsoft IT は、Microsoft Operations Manager (MOM) 2005 を使用して、Microsoft Exchange Server の状態とパフォーマンスを監視します。MOM は、エラー -1018 などの重大なエラーについて、オペレータ コンソールに警告を送信します。
MOM は、IT 運用の効率を向上させるために、企業向けの運用管理機能を提供します。MOM の詳細については、Microsoft Windows Server System の Web サイトを参照してください。
Microsoft では、-1018 エラーが発生するたびに、指定されたハードウェア アナリストのグループに電子メール通知が自動送信されます。そのため、すべての -1018 エラーは、長期にわたってあらゆるサーバーのエラーを追跡する経験豊富な担当者グループによって調査されます。この記事で後述するように、このアプローチは、Microsoft での -1018 エラーの処理方法において重要な部分を担います。
バックアップの成功の監視
すべての組織では、その規模にかかわらず、Exchange サーバーのエラー -1018 を監視する必要があります。組織で MOM などの監視アプリケーションを使用していない場合、この監視を行うための最も基本的な方法は、各 Exchange オンライン バックアップの成功を確認することです。MOM を使用している場合でも、バックアップの成功を個別に監視する必要があります。
Exchange オンライン バックアップが監視されないと、少なくとも次の点においてリスクがあります。
| • | バックアップ失敗の一般的な理由は、データベースの損傷である - これが原因で、Exchange プラットフォームに突然障害が発生する危険性があります。 |
| • | 重要な Exchange データの最新の正常なバックアップがない - ゼロ損失で復元するために古いバックアップを追加のトランザクション ログでロール フォワードできますが、バックアップが古いほど、いくつかの運用上の理由から成功の可能性が低くなります。たとえば、古いバックアップ テープが間違ってリサイクルされることがあります。また、Exchange サーバーのプラットフォームの問題によりトランザクション ログが失われた場合、ロール フォワードは不可能になります。 |
| • | オンライン バックアップが正常に完了した後、過剰なトランザクション ログがディスクから自動的に削除される - バックアップが完了しなかった場合、トランザクション ログ ファイルはディスクに残るため、トランザクション ログ ドライブ上のディスク領域が最終的に不足する危険性があります。これにより、影響を受けるストレージ グループ内のすべてのデータベースが強制的にマウント解除されます。トランザクション ログ ドライブがいっぱいになった場合は、単純にすべてのログ ファイルを削除することはしないでください。代わりに、マイクロソフト サポート技術情報の記事「安全に移動できるトランザクション ログ ファイルを特定する方法」を参照してください。 |
バックアップ成功の検証は、間違いなく Exchange 管理者の最重要監視タスクである -
ベスト プラクティスとして、Microsoft IT は、バックアップ エラーと障害だけでなくバックアップの成功についても通知と警告を設定しています。各データベースの日次レポートが生成され、管理者によってレビューされます。このレビューにより、各データベースが最近実際にバックアップされ、各バックアップ障害に対して直ちに措置が取られていることが明確に確認されます。
-1018 エラー発生後のデータの保護
-1018 エラーが、Microsoft IT アナリストの注意を引くことが最も多いのは、バックアップ障害が原因の場合です。-1018 エラーは通常のデータベース操作中に発生する可能性がありますが、通常の実行時の -1018 エラーはバックアップ中のエラーよりも発生頻度が低くなります。
注 : Exchange データベースは、定期的なスケジュール (管理者が設定可能) に基づいて複数の自動保守タスクを実行します。これらのタスクの 1 つはオンライン最適化で、効率を高めるためにデータベース内のページを整理して移動します。このため、エラー -1018 がレポートされる頻度は、通常の実行時よりもオンライン保守期間中の方が高くなります。
次に、-1018 エラー発生後に Microsoft で行われる一般的なプロセスを示します。
| • | MOM 警告が生成され、Exchange アナリストに電子メール通知が送信されます。 |
| • | サーバー上のすべてのデータベースに対して最新の正常なバックアップが存在することが確認されます。 |
| • | トランザクション ログ ドライブに障害がある場合は、サーバー上のすべてのトランザクション ログ ファイルがリモートの場所にコピーされます。調査が進むと、新しいログ ファイルが安全な場所に定期的にコピーされるか、増分バックアップが行われます。 |
既存の Exchange データが復旧可能で安全であると確認された後、サーバーの評価と根本的な原因の分析が開始されます。
サーバー評価と根本的な原因の分析
次の 2 つのレベルで -1018 エラーの重大度を測定する必要があります。
| • | エラーがデータベースの機能に与える直接的な影響 |
| • | 緊急の復旧が必要な大多数の状況では新たな障害発生および障害の拡大の可能性 |
この 2 つの要因は、相互に独立しています。損傷したページが重要でないという理由で -1018 エラーを無視することは誤りです。次に破壊されるページが重要であるために、致命的なデータベースの障害が突然発生する可能性があります。
-1018 の状態では、2 つの一般的な分析と復旧のシナリオがあります。
| • | エラーが 1 つのみで、サーバーの全体的な機能に対する影響が小さいか、直接には影響しない場合。この場合は慎重に診断する時間があるため、影響の少ない復旧戦略を計画し、スケジュールします。ただし、サーバーはエラーの存在以外に障害の明白な形跡を示さないため、根本的な原因の分析は難しい可能性があります。 |
| • | サーバー上の他の重大な障害と共に、複数のページの損傷またはエラーが発生する場合。この場合は緊急の復旧が必要です。 |
緊急の復旧が必要な大多数の状況では、-1018 エラーがハードウェアの致命的または明白な障害を原因とする可能性が非常に高いため、根本的な原因の分析は単純です。緊急の状況でも、サーバーの統計的な傾向を見極めるのに必要なエラーに関する基本情報を保存する時間が必要です。詳細については、この記事の「付録 B: -1018 レコードの保持」を参照してください。
根本的な原因の分析前でも、最も優先順位が高いのは、既にバックアップされている既存のデータと最新のトランザクション ログ ファイルが保護されていることの確認です。その後で、ブックエンディングでの分析を開始できます。
ブックエンディング
ページが実際に損傷したポイントおよび -1018 エラーがレポートされたポイントは、時間的に離れている場合があります。-1018 エラーがレポートされるのは、ページがデータベースによって読み取られるときだけであるためです。ブックエンディングは、損傷が発生した時間範囲を指定するプロセスです。
ブックエンドの開始は、データベースに対して最後の正常なオンライン バックアップが行われた時刻です (イベント 221 で示されます)。バックアップ中にデータベース全体で -1018 の問題がチェックされるため、バックアップが終了するまで問題が発生しなかったことがわかります。もう一方のブックエンドは、-1018 エラーがアプリケーション ログに実際にレポートされた時刻です。多くの場合、これはバックアップ障害エラー (イベント 217) です。-1018 エラーの原因となったイベントは、必ずこの 2 つのポイントの間に発生しています。
ブックエンドを設定した後、次のタスクは、この期間中に -1018 エラーの原因となったサーバーで他に何が起きたかを調べることです。
| • | ハード サーバーまたはディスクに障害が発生したか。 |
| • | サーバーが再起動されたか (システム ログにイベント 6008 が記録されているか)。 |
| • | Exchange サービスが停止して再開されたか。 |
| • | ストレージ関連のエラーが発生したか。これには、メモリ、ディスク、マルチパス、およびコントローラのエラーが含まれます。Windows システム ログを検索するだけでなく、ディスク システムで使用されている可能性のある他のログ メカニズムも確認する必要があります。多くの外部ストレージ コントローラはイベントを Windows システムやアプリケーション ログに記録せず、既定では、コントローラはエラーをログに記録するようには設定されない場合があります。エラー ログが有効になっていること、またログを特定して解釈できることを確認する必要があります。 |
| • | Exchange データを保持しているすべてのボリュームに対して Chkdsk を実行したか。 |
| • | クラスタ化されているサーバーの場合、フェールオーバーまたはその他のクラスタ状態の遷移があったか。 |
| • | ハードウェアの変更が行われたか、またはサーバーのファームウェアやソフトウェアがアップグレードされたか。 |
ブックエンド時刻間に発生した例外的なイベントは、問題の原因となっている疑いがあると考える必要があります。データベース ファイルの損傷の原因と考えられる例外的なイベントがない場合は、基礎となるプラットフォームの信頼性に関して、検出されない問題がある可能性を検討する必要があります。
エラーの原因が、ハードウェアに関係のない一時的条件である可能性もあります。さまざまな環境要因により、コンピュータ データが損傷したり、一時的な誤作動の原因となったりすることがあります。振動、熱、電圧変動、および宇宙線さえも、故障や永久的な損傷の原因となることが知られています。ハード ドライブの製造元は、正常に機能するドライブでもデータの読み取り、書き込み、および格納を 100% 確実には行えないことをよく認識しており、エラーの検出と破損データの再書き込みを行うようにシステムを設計しています。
コンピュータ ストレージ システムに 100% の信頼性はないことを念頭に置いた場合、-1018 エラーが、対処する必要のある内在的な問題を示しているのか、許容する必要のあるランダムな発生にすぎないのかはどのように判断すればよいでしょうか。
ディスクの障害および Exchange の -1018 エラーの根本的な原因の分析に幅広い経験を持つ Microsoft シニア ストレージ テクノロジストは、次の原則を提案しています。類似するハードウェアに対して実行している 100 台の Exchange サーバーでは、-1018 エラーの発生は年間 1 回以下である必要があります。類似するハードウェアで実行しているという部分が、この原則の正しい適用を理解するときに重要です。
Exchange の単一ハードウェア プラットフォームでの標準化は、-1018 エラーの根本的な原因の分析に役立ちます。明らかな根本原因がない場合、調査の次の手順は、類似するサーバーでエラーのパターンを探すことです。
単一ページでの単一の -1018 エラーは、ランダムなイベントである可能性があります。別の -1018 エラーが同じサーバーまたは類似するサーバーで発生した後にのみ、傾向または共通原因を探し始めるのに十分な情報を入手できます。-1018 エラーが、共通点のない 2 台のサーバーで発生した場合は、パターンを明らかにする可能性のある 2 つのデータ ポイントではなく、共通点のない 2 つのエラーがあることになります。
一般に、同じ種類の 100 台のサーバーで -1018 エラーの発生回数が年間 1 回以下の場合は、根本的な原因の分析により対応可能な問題が明らかになる見込みはありません。
これは、サーバーで発生する各 -1018 エラーのデータを記録する必要がないということを意味しているのではありません。第 2 のエラーが発生するまでは、特定のエラーがこの原則のしきい値を下回るかどうかはわかりません。
-1018 エラーの原因が気付きにくいハードウェアの問題である場合は、複数のエラーからのデータを提供することが不可欠です。検討するエラーが 1 つしかない場合は、ユーザー自身が特定できること以外に Microsoft またはハードウェア ベンダが根本的な原因を特定するのは難しい可能性があります。2 つの実際の -1018 エラーの根本原因の調査、およびいくつかの問題の分析がどれほど困難で捕らえにくいかの例については、この記事の「付録 A: ケース スタディ」を参照してください。
Microsoft で発生したすべての -1018 エラーに関する詳細情報は、この記事の「付録 B: -1018 レコードの保持」で説明するように、スプレッドシートに記録されています。
損傷の範囲の確認
エラー -1018 は、データベースの個々のページの問題に適用され、データベース全体には適用されません。-1018 エラーがレポートされた場合に、レポートされたページが唯一の損傷ページであるとは想定できません。バックアップは最初の -1018 が発生した時点で停止するため、バックアップ中にレポートされたエラーに依存して損傷の範囲全体を示すこともできません。
復旧戦略を決定する際に、データベース内で損傷しているページ数を知る必要があります。複数のページが損傷している場合は複数のエラーが発生している可能性があり、プラットフォームで全面的な障害が発生する危険が差し迫っていると見なす必要があります。
Microsoft IT が調査した -1018 エラーのケースの大多数では、データベースには単一の損傷ページしかありませんでした。この状況では、内在的な問題を示すものが他になく、Microsoft IT は、サーバーを稼動させたままにし、ピーク外の時間まで復旧の実装を待ちました。近い将来の第 2 のエラーまたは他のサーバーでの類似する問題によって傾向が示されない限り、これはランダムなエラーであると想定されます。
注 : エラー -1018 が発生するとオンライン バックアップが完了しないことを覚えておいてください。データベースの復旧を遅延させると、古いバックアップで増分的に復旧する必要があります。この状況では、追加のトランザクション ログ ファイルを再生する必要があるため、復旧のための停止時間が確実に長くなります。Exchange Server 2003 SP1 では、ログ ファイル再生の一般的なパフォーマンスは、再生する必要のあるログ ファイル数にかかわらず、パフォーマンスの一貫性を保った状態で 1 時間に 1,000 個以上のログ ファイルを再生できます。以前のバージョンの Exchange では、トランザクション ログ ファイルの再生が 5 倍以上遅い可能性があり、再生するログが多いほど再生の平均速度が低下する傾向にあります。
データベース全体で -1018 エラーのページを包括的にテストするには、データベースをオフラインにし、Eseutil をチェックサム モードで実行する必要があります。
-1018 エラーの発生後にデータベースを停止すると、二度と起動しない可能性があります。他の不明なページも損傷していた場合、それらの 1 つがデータベースの起動に不可欠である可能性があります。統計的にはこのリスクは可能性が低く、Microsoft IT では、実行時に -1018 エラーを表示したデータベースを躊躇せずマウント解除します。
Eseutil は、すべての Exchange サーバーの \exchsrvr\bin フォルダにインストールされています。チェックサム モードで (/K スイッチを指定して) 実行した場合、Eseutil はデータベース内のすべてのページを高速にスキャンし、ページが正しい場所にあるかどうか、またそのチェックサムが正しいかどうかを確認します。Eseutil は、サーバーで実行されている他のアプリケーションに関係なく、できるだけ高速に実行されます。他のデータベースと共有されているデータベース ドライブで Eseutil /K を実行すると、他の稼動中のデータベースのパフォーマンスに悪影響を及ぼす可能性があります。このため、できるだけピーク外の時間にデータベースのテストをスケジュールする必要があります。
注 : Exchange データベースを別のハードウェアにコピーして保護することに決めた場合は、移動ではなくコピーしてください。現在のプラットフォーム上の問題はディスク システムにあるわけではありませんが、移動プロセス中に破損の原因となることがあります。ファイルを移動する場合にこの破損が発生すると、データベースは復旧できなくなります。
Microsoft では、Eseutil チェックサム検証を、Eseutil の複数のコピーをデータベースに対して同時に実行することで行います。Eseutil /K の 1 つのインスタンスをデータベースに対して起動し、1 分後に、別のインスタンスを同じデータベースに対して起動します。ミラー セットでは、ミラーの一方の側に不良ページがあり、もう一方の側にない場合があるからです。
Eseutil の 2 つのコピーをわずかに非同期に実行すると、ミラーの両方の側が読み取られる可能性がはるかに高くなります。ミラーの一方の側が良好で、一方の側が不良であることはあまり多くありませんが、可能性がないわけではないため、徹底したテストではミラーの両側をテストする必要があります。また、Microsoft ではこの Eseutil 方式を連続して 5 回実行し、結果の信頼レベルを向上させています。
注 : Eseutil /K の複数回の実行は、データが複数のディスクにパリティ付きでストライプ化されている RAID-5 ストライプ セットにデータベースが格納されている場合には不要です。セット内の特定のページのコピーは 1 つしかなく、失われたドライブの内容をパリティから再構築する機能により冗長性が実現されるからです。また原則として、パフォーマンス上の理由から、負荷の高いデータベース ドライブには、RAID 1 (ミラー化) または RAID 1+0 (ミラー化 + ストライプ化) ドライブ セットをお勧めします。
-1018 エラーからの回復
Microsoft IT は、-1018 エラーから復旧するために 2 つの基本タスクを実行します。
| • | エラーの原因となった根本的な問題を修正します。 |
| • | エラーにより損傷した Exchange データを復旧します。 |
これらのタスクは、相互に完全には独立していません。根本的な原因について検出された内容は、データ復旧戦略に影響する場合があります。
たとえば、サーバー ハードウェアが完全に故障する危険が差し迫っているという明白な徴候がある場合、データ復旧戦略には、別のサーバーへの即時のデータ移行が必要になります。サーバーが安定しているように見える場合、データ復旧では、データベースから不良ページを削除するためのバックアップからの復元のみ行います。
サーバーの復旧
Microsoft では、単一の -1018 エラーの場合はサーバーを監視対象の一覧に含めます。エラーの原因となったコンポーネントが明確に特定されていない限り、ハードウェアの交換や撤去は行いません。近い将来に同じサーバーで新たな -1018 エラーが発生した場合は、根本的な原因が明確に判断されたかどうかにかかわらず、サーバーは信頼性のないものとして扱われます。そのサーバーは運用環境から除外され、広範なテストが行われます。
-1018 エラーの発生後にサーバーを即時に停止し、製造元の一連の診断テストをすべて実行する必要があるのは明らかだと思える場合があります。しかし、Microsoft IT ではこれを当然のこととしては行いません。標準診断テストによって -1018 エラーの根本的な原因が明らかになることはまれだからです。その理由は次のとおりです。
| • | 破損は環境の異常が原因の場合がある - 電圧変動や干渉、熱や湿度の一時的な上昇、および宇宙線さえも、コンピュータ データを破損させることがあります。テストの実行時にこれらの条件が繰り返されない限り、テストでは何も示されません。 |
| • | -1018 エラーの発生が 1 回のみで、他に表示されるエラーや問題を伴わない場合は、現在サーバーが正常に機能している可能性が高い - 問題の原因となった条件が、頻繁には発生しないか、汎用診断ツールでは再現できない特定の状況の集合による場合があります。 |
| • | ハードウェアの障害は、規則的または連続的なパターンではなく断続的に発生することが多い。 |
| • | 問題は、連続的に障害が発生するコンポーネントが原因ではなく、ハードウェアまたはファームウェアの捕らえにくいバグが原因の場合がある - この場合、通常の製造元の診断テストでは問題を明らかにできない可能性があります。これらの診断で問題を検出できる場合は、それ以前の診断テスト実行時に既に明らかにされているはずです。 |
| • | 問題はハイゼンベルクである可能性がある - ハイゼンベルクという用語は、システムの観察に使用される診断ツールによって問題が再発しないようにシステムが変更されるため、問題が再現できなくなることを意味します。たとえば、RAM の内容を監視するツールが処理速度を低下させたため、タイミングの許容範囲を超えず、問題が消失してしまう場合があります。 |
| • | 診断ツールは、サーバーに対する複雑すぎる負荷をシミュレートできない場合がある - システムを I/O 負荷の大きい状態で稼動させた場合、-1018 エラーが発生しやすくなるというのは誤った認識です。Microsoft の経験では、全体的な負荷レベルよりも、負荷の複雑さの方がデータ破損の問題の発生に大きく関与します。複雑さはアクセスの種類 (I/O サイズと方向の組み合わせ)、および実際のデータ内容のパターンに存在する可能性があります。特定の複雑なパターンは、より単純なパターンでは現れないノイズや混信を示すことがあります。Finisar Medusa Labs Test Tool Suite の長所の 1 つは、このようなパターンを生成する機能があることです。 |
一般に製造元の診断テストは、サーバーが既に運用から除外された後でのみ実行されます。これは、-1018 エラーのパターンが内在的な問題の存在を確定し、根本的な原因がまだ検出されていない場合に行われます。これらの診断テストと共に、Microsoft IT では、ディスク サブシステムに負荷をかけるツールを使用してデータの破損の問題を再現することを試みます。
Jetstress (Jetstress.exe) および Exchange Server Load Simulator (LoadSim) ツールを使用して、実際の Exchange サーバーの I/O 負荷要求を実質的にシミュレートできます。これらのツールの主要機能は、キャパシティ計画と検証を目的としていますが、ハードウェア機能のテストにも役立ちます。
Jetstress は、複数の Exchange データベースを作成し、現実的な Exchange データベース I/O 要求でデータベースをテストします。この方法を使用すると、ディスク システムの I/O 帯域幅が使用目的に照らして十分かどうかを判断できます。
LoadSim は、メッセージング アプリケーション プログラミング インターフェイス (MAPI) クライアント (Microsoft Office Outlook 2003) のアクティビティを Exchange サーバーに対してシミュレートし、サーバーとネットワークの全体的なパフォーマンスの判定に役立ちます。LoadSim は、サーバーに高レベルのクライアント負荷を与えるために追加のクライアント ワークステーション コンピュータを必要とします。
どちらのツールもディスク診断に使用することが目的ではありませんが、どちらも現実的な大量の Exchange ディスク I/O を作成するのに使用できます。この目的では、Jetstress の方がセットアップと調整が簡単であるため、ほとんどのユーザーはこのツールの使用を選択します。Jetstress と LoadSim には、詳細なドキュメントとセットアップ ガイドが付属しており、Microsoft から無料でダウンロードできます。Microsoft ダウンロード センターから Jetstress をダウンロード (英語) できます。LoadSim は、Microsoft Windows Server System の Web サイトからダウンロードできます。
Microsoft IT では、ディスク システムの高度なストレス テストに Finisar 社の Medusa Labs Test Tools Suite も使用します。Finisar ツールでは、複雑な特定の I/O パターンを生成できます。このツールは、企業向けのシステムおよびストレージの信頼性のテストを目的として設計されています。Jetstress と LoadSim は現実的な Exchange サーバー負荷を生成できますが、Finisar ツールは、データおよびシグナル インテグリティの捕らえにくい問題を明らかにするため、さらに複雑で要求の多い I/O パターンを生成します。
Medusa Labs Test Tools Suite の詳細については、Finisar 社の Web サイト (英語) を参照してください。
Jetstress、LoadSim、または Medusa ツールを使用するには、サーバーを運用サービスから除外する必要があります。ストレス テスト構成でこれらの各ツールを使用すると、テストの実行中は他の目的でサーバーを使用できなくなります。
Eseutil チェックサム機能も、ディスク システムの信頼性の欠如の再現に役立つことがあります。Eseutil は、データベースをできるだけ高速にスキャンし、各ページを読み取って、そこにあるべきチェックサムを計算します。このツールは、使用可能なディスク I/O 帯域幅をすべて使用します。これにより、サーバーの I/O 負荷は大きくなりますが、特に複雑な負荷は課されません。連続的な Eseutil の実行でページのさまざまな損傷がレポートされる場合は、ディスク システムに信頼性がないことを示しています。これは、比較的明白な問題を明らかにするための単純なテストです。このテストに失敗したディスク システムは、運用環境で Exchange データをホスティングするための信頼性がありません。ただし、Eseutil チェックサム機能ではシステムの捕らえにくい問題が発見されることはありません。
チェックサム検証された大きなファイル (Exchange データベースなど) をあるディスクから別のディスクへコピーするテストもよく行われます。ファイル コピーがエラーで失敗した場合、またはコピーされたファイルがソースと同一でない場合は、サーバー上に重大なディスク関連の問題があることを強く示しています。
サーバーの復旧に関する最後の注意事項として、Exchange サーバーとディスク サブシステムが、製造元が推奨する最新ファームウェアとドライバを使用して実行されていることを確認する必要があります。これらを使用して実行されていない場合は、アップグレードによって内在的な問題が解決する可能性があります。
Microsoft は、-1018 エラーのパターンが特定のコンポーネントまたは構成に関連している場合に製造元と密接に協力し、ハードウェア製造元は自社のシステムの改善とアップグレードを継続的に行っています。まれに、-1018 エラーが新規ドライバの適用またはアップグレードの直後に発生し始めることがあります。この場合も、標準化されたハードウェア プラットフォームによってパターンのトラブルシューティングと認識が簡単になる可能性があります。
データの復旧
データ復旧戦略について決定するときに答える必要のある最初の質問は、データベースがまだ稼動しているかどうかということです。
データベースが稼動している場合は、操作の継続に不可欠なデータベース部分がエラーによって損傷していないことがわかります。一部のユーザー データが既に失われている可能性はありますが、おそらく消失の範囲は限定されています。
次の質問は、サーバーを運用環境で使用するのに十分な信頼性がまだあると確信できるかということです。
Microsoft では、サーバーで単一の -1018 エラーが発生し、システムの不安定性を示す要素が他にない場合は、サーバーが十分に良好であり、無期限に運用環境に残してもかまわないと判断します。この結論により、新たなエラーが発生することがあります。
データ復旧戦略を決定する前に、その戦略を実行する緊急度を評価する必要があります。データベースの現在の状態と共に、根本的な原因の分析から既に学習した内容が、この評価の重要な要素になります。検討する必要のある質問は次のとおりです。
| • | 複数のエラーが発生したか - 複数のエラーが発生した場合、またはトラブルシューティング中に新たなエラーが発生した場合は、プラットフォーム全体に突然障害が発生する可能性が高いと考える必要があります。 |
| • | 複数のデータベースが関係しているか。 |
| • | プラットフォームは明らかに不安定になっているか - たとえば、根本的な原因の分析において、問題のあるディスクへの大きなファイルのコピーでエラーが必ず発生することを発見したとします。この時点で、データベースを別のプラットフォームに即時に移動する緊急度がはるかに高まります。 |
| • | 影響を受けるデータの最新のバックアップがあるか - バックアップの成功を監視していなかった場合、データベースが既に損傷していたために、バックアップが数日または数週間失敗していた可能性があります。サーバーに突然障害が発生した場合は、さらにリスクが高くなります。 |
正常な最新のオンライン バックアップがない場合は、データベースを停止し、データベース ファイルをサーバーから安全な場所にコピーすることを最優先にする必要があります。最新のオンライン バックアップがなく、オフライン バックアップを行っていない場合は、データベースのその後の損傷により修復不能になり、致命的なデータ損失を引き起こすおそれがあります。
データベースが既に損傷しているのは確かですが、損傷があまり広範囲にわたっていない限り、Eseutil を使用して修復できます。データベースの修復の詳細については、この記事で後述します。
Microsoft IT では、-1018 エラーの発生後にデータベースを復旧する方法を、いくつかの標準的な戦略の中から選択します。以降の各節では、各戦略の長所および短所と共に、戦略を使用するために必要な前提条件を概説します。
バックアップからの復元
正常であることがわかっているバックアップからの復元とデータベースのロール フォワードは、損傷しているデータベース ページ数にかかわらず、データのゼロ損失を保証する唯一の戦略です。この戦略には、バックアップ時から現在までのすべてのトランザクション ログの可用性と整合性が必要です。
この戦略によりデータのゼロ損失が実現される理由は、Exchange が永久的な -1018 エラーの損傷をページで検出した後、そのページが再び使用または更新されることはないからです。データベースのバックアップ コピーがページの最新バージョンを保持しているか、またはバックアップ時以後のいずれかのトランザクション ログが損傷前にページに対して行われた最後の変更を保持しているという 2 つの条件のうちの 1 つが適用されます。このため、復元およびロール フォワードによって、データ損失なしに不良ページが抹消されます。
注 : バックアップから復元する前に、現在のデータベースのコピーを必ず作成する必要があります。データベースが損傷している場合でも、修復可能な場合があります。バックアップから復元する場合、現在のデータベースは、復元プロセスの最初に上書きされます。復元に失敗しても、損傷したデータベースのコピーがある場合は、復旧戦略としてのデータベースの修復に戻ることができます。
バックアップからの復元は、Microsoft IT が -1018 エラーから復旧するために最も頻繁に使用する方法です。Microsoft の各 Exchange データベースはサイズが調整されているため、約 1 時間で復元できます。
復元は、他の復旧戦略よりもはるかに高速な処理です。サーバーが十分に安定していると想定した場合、復元をピーク外の時間にスケジュールすると、エンド ユーザーへの影響が最小限になります。Microsoft が Exchange をバックアップする方法の詳細については、「IT Showcase」の記事「Backup Process Used with Clustered Exchange Server 2003 Servers at Microsoft」(英語) を参照してください。
新規データベースへの移行
Exchange システム マネージャには、あるデータベースまたはサーバーから別のデータベースまたはサーバーにすべてのメールボックス データを移動するためのメールボックスの移動機能が用意されています。これは、データベースがオンラインのとき、またはユーザーがメールボックスにログオンしているときに行うことができます。ただし、ほとんどの Exchange 管理者は、各メールボックスの移動中に個々のユーザーが短時間の切断を経験しないように、メールボックスの移動時に全体の機能停止をスケジュールすることを選択します。
Exchange Server 2003 では、メールボックスの移動をスケジュールし、バッチ処理できます。Microsoft Office Outlook の Exchange キャッシュ モードと連携して、各メールボックスが移動されるときのサービスの中断はエンド ユーザーに気付かれないことが多く、エンド ユーザーはメールボックスのキャッシュされたコピーから作業を続行できます。
パブリック フォルダ データベースの場合、各フォルダはレプリケーションによって別のサーバーに移行できます。すべてのフォルダの追加のレプリカが他のサーバーに既に存在している場合は、問題のあるデータベースからすべてのレプリカを削除することにより、すべてのデータを移行できます。これは、このデータベースから他のレプリカへのフォルダの最終同期のトリガとなります。
Exchange システム マネージャにより、パブリック フォルダ データベース内のすべてのフォルダに対するレプリケーションが終了したことが示された後で、元のデータベース ファイルを削除できます。ファイルの削除後にデータベースを再びマウントすると、新しい空のデータベースが生成されます。その後で、他のパブリック フォルダ サーバーからこの新しいデータベースに必要に応じてフォルダをレプリケートできます。
別のデータベースにデータを移行しても、不良ページは移動またはレプリケーションの操作中に使用されないため、-1018 または 1019 の問題は残ります。復元およびロール フォワード戦略を使用する場合とは異なり、データの移行では、不良なページ上にあった情報は復旧されません。そのため、不良なデータは確実に残されています。
特定のメッセージ、フォルダ、またはメールボックスの移動に失敗し、アプリケーション ログで同時に記録された -1018 エラーに気付く場合があります。これにより、エラーおよびその影響を受けたデータを特定できます。Exchange Server 2003 では、新しいメールボックス移動ログで、移動に失敗した各メッセージに関する詳細をレポートできます。または、一括移動操作中に、エラーを示すメールボックスをスキップできます。メールボックス移動操作の構成、バッチ処理、およびログ記録の詳細については、Exchange Server 2003 のオンライン ヘルプを参照してください。
単一の不良ページが複数のユーザーに影響を与えることがあります。これは、単一インスタンス ストレージが原因です。Exchange データベースでは、メッセージのコピーが複数のユーザーに送信された場合、そのメッセージのコピーが 1 つだけ格納され、すべてのユーザーがそのコピーへのリンクを共有します。
データベース内に -1018 の問題があることがわかっている場合でも、データの移行がエラーなく完了することがあります。この状況は、セカンダリ インデックスなどのデータベース構造に不良ページがある場合に発生します。このような構造は移動されず、データの移行後に再構築されます。メールボックスの移動またはレプリケーション操作がエラーなく完了した場合は、不良ページが再構築可能なデータベース セクション、またはセカンダリ インデックスなどの破棄可能な構造にあったことを示しています。このような場合は、データベースからの移行によってゼロ損失でデータが復旧されます。
50 GB のデータベースのすべてのデータを移行またはレプリケートするには、1 〜 2 日かかる場合があります。このため、移行戦略を選択する場合は、操作を完了するのに十分な時間、サーバーが安定してサービスを継続できるという保証が必要です。
データベースの修復
Eseutil およびインフォメーション ストア整合性チェッカー (Isinteg.exe) ツールは、すべての Exchange サーバーおよび管理ワークステーションにインストールされます。これらのツールを使用して、データベースから不良ページを削除し、他のデータとの論理的な一貫性を復元できます。
データベースを修復すると、通常は一部のデータが失われます。Exchange は不良ページを読み取りがまったく不可能なページとして処理するため、ページ上にあったデータは修復によって復旧されません。不良ページが破棄または再構築可能な構造に存在する場合は、ゼロ損失でデータを修復できることがあります。Exchange データベースのページの大多数にはユーザー データが格納されています。このため、修復でデータ損失が生じない可能性はごくわずかです。
修復は複数の段階から構成される手順が必要です。
1. | データベース ファイルのコピーを安全で安定した場所に作成します。 |
2. | Eseutil を修復モード (/P コマンド ライン スイッチを指定) で実行します。これにより、不良ページが削除され、個々のデータベース テーブルとの論理的な一貫性が復元されます。 |
3. | Eseutil をデフラグ モード (/D コマンド ライン スイッチを指定) で実行します。これにより、データベース内にセカンダリ インデックスと領域ツリーが再構築されます。 |
4. | Isinteg を修正モード (-Fix コマンド ライン スイッチを指定) で実行します。これにより、アプリケーション レベルでデータベースとの論理的な一貫性が復元されます。たとえば、修復中に複数のメッセージが失われた場合、Isinteg はフォルダ アイテム数を調整してこれを反映し、欠落しているメッセージ ヘッダー行をフォルダから削除します。 |
通常、データベースの修復は、バックアップから復元してロール フォワードする場合よりもはるかに長い時間がかかります。必要な時間は、損傷の性質とシステムのパフォーマンスによって異なります。多くの場合、修復プロセスには、10 GB のデータで約 1 時間かかります。ただし、この時間数よりも数倍高速または低速なことも珍しくありません。
修復には、追加のディスク領域も必要です。データベース ファイルのサイズと同等の領域が必要になります。この領域が同じドライブ上で使用可能でない場合は、他のドライブまたはサーバー上の一時ファイルを指定できますが、その場合は修復の速度が大幅に低下します。
修復は低速で、通常はある程度データが失われるため、バックアップから復元してデータベースをロール フォワードできない場合にのみ、復旧戦略として使用する必要があります。
正常なバックアップがあっても、データベースをロール フォワードできない場合があります。その場合は、復元戦略と修復戦略を組み合わせると、最大限のデータ量を復旧できます。このオプションについては、次の節で詳細に説明します。
データベース修復ツールは、Exchange の最初のバージョンがリリースされてから継続的に改訂および強化されており、通常はデータベースに完全な論理的一貫性を復元するのに効果的です。修復は効果的ですが、Microsoft IT では、修復は復元が不可能な場合にのみ使用する非常事態戦略と考えています。Microsoft IT は Exchange のバックアップ手順に厳格であるため、修復は次の節で説明するハイブリッド戦略の一部として以外はほぼ使用しません。
データベースを修復した後の Microsoft IT の方針は、修復したデータベースを運用環境で無期限に実行するのではなく、すべてのフォルダまたはメールボックスを新しいデータベースに移行することです。
データの復元、修復、およびマージ
大規模な障害により必要なトランザクション ログ ファイルが破棄されたため、復元したデータベースでロール フォワードできない場合は、ハイブリッド修復戦略を使用できます。
このシナリオでは、古いけれども正常なデータベースのコピーがバックアップから復元されます。ゼロ損失の復旧に必要なトランザクション ログは使用不能であるため、復元したデータベースでは、バックアップ作成後のすべての変更が欠落しています。
ただし、損傷したデータベースにはこの欠落データの大部分が含まれている可能性があります。目標は、損傷したデータベースの内容を復元したデータベースとマージすることにより、最小限のデータ損失で復旧することです。
この処理を行うために、損傷したデータベースが別の場所に移動されます。その場所では、復元したデータベースが稼動してユーザーにサービスを提供している間に、データベースを修復できます。Exchange Server 2003 では、ストレージ グループの復旧機能を使用して、同じサーバー上で復元と修復を行うことができます。以前のバージョンの Exchange では、データベースを別のサーバーにコピーして修復し、データをマージする必要がありました。
メールボックス データベース間の一括マージは、次の 2 とおりの方法で実行できます。
| • | メールボックス マージ ウィザード (ExMerge) の実行 - Microsoft ダウンロード センターから ExMerge をダウンロード (英語) できます。ExMerge は、重複するメッセージのコピーを抑制し、タイムスタンプ、フォルダ、およびその他の条件に基づいてデータのマージをフィルタ処理できるようにして、データベース間のメールボックスの内容をコピーします。ExMerge は、メールボックス データを抽出およびインポートするための強力で洗練されたツールです。 |
| • | Exchange Server 2003 SP1 の Exchange システム管理者の回復用ストレージ グループ ウィザードの使用 - 回復用ストレージ グループ ウィザードは、回復用ストレージ グループにマウントされているデータベースのメールボックスの内容を、マウントされている元のデータベースのコピーにマージします。ExMerge と同様に、回復用ストレージ グループ ウィザードは重複を抑制しますが、他のフィルタ処理の選択肢は提供されません。データ復旧操作の大多数で必要なのは、重複の抑制のみです。ほとんどの場合、回復用ストレージ グループ ウィザードは、ExMerge のコア機能を提供しますが、使用方法はより単純です。 |
代替サーバーの復元
Exchange では、あるサーバーで作成したバックアップを別のサーバーに復元できます。このシナリオでは、ストレージ グループとデータベースを復元先サーバーに作成し、バックアップをそのサーバーに復元します。あるサーバーから別のサーバーにログ ファイルをコピーしてデータベースをロール フォワードすることもできます。
元のサーバーの状態が急速に悪化し、データベースをホスティングする別の場所をすぐに探す必要がある場合に、この戦略が必要になることがあります。データベースのオンライン バックアップまたはオフライン コピーを別のサーバーに復元できます。
データベースが復元された後で、Active Directory® ディレクトリ サービス アカウントを新しいサーバーに置かれたメールボックスにリダイレクトする必要があります。この処理は、次の手順で行うことができます。
| • | Exchange Server 2003 で、データベース内にメールボックスを持つすべてのユーザーに対して Exchange 属性の削除タスクを行った後、メールボックス回復センターを使用してすべてのユーザーを新規サーバーのメールボックスに自動的に再接続します。 |
| • | Active Directory 属性変更のスクリプトを使用して、Active Directory アカウントを新規サーバーにリダイレクトします。 |
これは高度な戦略です。この戦略の使用が必要になり、過去にこの戦略に成功したことがない場合は、Microsoft 製品サポート サービスにご相談ください。この戦略には、クライアントの Outlook プロファイルの編集または再作成も必要です。
ベスト プラクティス
Microsoft IT は、世界中の 100,000 個のメールボックスをホスティングしている約 95 台の Exchange メールボックス サーバーを管理しています。昨年、これらすべてのサーバーでエラー -1018 が合計 6 件発生しましたが、エラーは 2 台のサーバーに限定されていました。
1 台のサーバーで 4 つのエラーが発生し、もう 1 台のサーバーで 2 つのエラーが発生しました。最初のケースでは、根本的な原因は、特定のハードウェア障害にトレースされました。2 台目のサーバーでは、2 つのエラーが非常に近い時間に発生しましたが、それ以降は発生していないため、現在も調査中です。
Microsoft IT は、一般的な傾向として -1018 エラー数が年々減っていることに気付きました。これは、Exchange の -1018 エラーが数年前よりも少なくなったという多くの Exchange 管理者の経験と一致しています。多くの場合、管理者は、Exchange の機能向上によってこれらのエラーが減少したと想定します。しかし、実際にはその賞賛は製品の信頼性とスケーラビリティを絶えず強化しているハードウェア ベンダに与えられるものです。Microsoft の主な貢献は、ベンダが解決した問題を指摘してきたことです。
企業向けの信頼性の高いハードウェアを Exchange システムに使用すると共に、Microsoft IT が使用したベスト プラクティスがいくつかあります。このベスト プラクティスを実装すると、データ ファイルが破損する可能性をさらに削減できます。
ハードウェア構成と保守
次のベスト プラクティスに従います。
| • | Exchange データを格納するディスク ドライブでのハードウェア ライトバック キャッシュを無効にするか、電源が遮断された場合にキャッシュ状態を維持できる信頼性の高いコントローラがあることを確認します。 |
| • | 製造元の推奨に従って、ディスク コントローラのキャッシュ バッテリ、無停電電源装置 (UPS)、およびその他の電源遮断復旧システムを変更します。バッテリの問題は、電源障害後のデータ損傷の一般的な原因となっています。 |
| • | 運用環境で使用する前にシステムをテストします。Microsoft IT は、新しい Exchange システムのバーンイン テストに Jetstress を使用します。Finisar 社の Medusa Labs Test Tool Suite は、通常、機能の低いツールでは問題を再現できず、高度な分析を行う場合にのみ Microsoft IT で使用されます。 |
| • | パフォーマンスとデータ整合性の両方の理由で、ディスク システムの実際のドライブ再構築およびホット スワップの機能のテストが必要です。ドライブ再構築の操作中にシステムのパフォーマンスが大きな影響を受け、使用不能になる可能性があります。ドライブ再構築の操作中にディスクに大きな負荷がかかっていた場合に、ドライブ再構築の機能が不安定になるケースもありました。 |
| • | 製造元によって推奨されている順序および方法で、サーバーとディスク システムの電源を切ります。システムの予想シャットダウン時間、およびハード シャットダウンが安全または危険であるポイントを知っておく必要があります。多くのサーバー システムは、コンシューマのコンピュータ システムよりもシャットダウンに時間がかかります。Microsoft 製品サポート サービスの経験では、シャットダウンを待てないことがデータ破損で非常に多い原因です。 |
| • | Exchange に使用するハードウェア プラットフォームを標準化します。これにより、一般的なサーバー管理性が向上するだけでなく、複数サーバーでのエラーのトラブルシューティングと分析も簡単になります。 |
| • | サーバー、ディスク コントローラ、スイッチやその他のファームウェア、およびディスクとディスク I/O を管理するソフトウェアのアップグレードを最新に保ちます。 |
| • | Exchange で使用するディスク コントローラがアトミック I/O をサポートしていることをベンダに確認し、アトミック値を調べます。 |
操作
次のベスト プラクティスに従います。
| • | Exchange データベースとトランザクション ログ ファイルを別々のディスク グループに配置します。原則として、Exchange ログ ファイルは、Exchange データベース ファイルと同じ物理ドライブ上には絶対に配置しないでください。これには次の 2 つの重要な理由があります。 |
| • | フォールト トレランス - Exchange データベース ファイルをホスティングしているディスクにトランザクション ログも保持されている場合、これらのディスクが消失すると、データベースとトランザクション ログ ファイルの両方が失われます。これにより、バックアップからのデータベースのロール フォワードが不可能になります。 |
| • | パフォーマンス - Exchange データベースのディスク I/O 特性は、大量のランダムな 4 KB の読み取りおよび書き込みであり、通常は書き込みの 2 倍の読み取りが行われます。Exchange トランザクション ログ ファイルでは、I/O は順次であり、書き込みのみで構成されます。原則として、順次とランダムの I/O ストリームを同じディスクに混在させると、パフォーマンスが大幅に低下します。 |
| • | すべての Exchange データ破損の問題を、すべての Exchange サーバーで追跡します。これにより、プラットフォームの捕らえにくい欠陥の傾向分析とトラブルシューティングのためのデータが提供されます。詳細については、この記事の「付録 B: -1018 レコードの保持」を参照してください。 |
| • | Windows イベント ログを保存します。ブックエンド期間中に生成されたイベント ログが消去されたり、自動的に上書きされたりすることはよくあります (詳細については、この記事の「ブックエンディング」を参照してください)。イベント ログは、根本的な原因の分析に重要です。Exchange をクラスタで実行している場合は、イベント ログのレプリケーションが構成されていることを確認するか、Exchange をアクティブに実行しているかどうかにかかわらず、クラスタ内のすべてのノードからイベント ログを収集して保存してください。 |
まとめ
ほとんどの組織では、大量の重要データが Microsoft Exchange データベース ファイルで管理されています。現在のサーバー クラス コンピュータ ハードウェアは、非常に信頼性がありますが完全ではありません。Exchange データ ファイルは GB または TB 単位のストレージを構成するため、データベース ファイルがストレージの障害によって損傷することがあるのは避けられません。
-1018 エラーの発生を歓迎する管理者はいませんが、このエラーはデータの破損が見逃されるのを防ぎ、多くの場合、問題が重大化して致命的なエラーが発生する前に早期の警告を行います。
すべての -1018 エラーはログに記録されます (付録 B で説明しています)。さらに、すべての -1018 エラーには、データ整合性を復元するための何らかの復旧戦略が必要です (「-1018 エラーから復旧する」で説明しました)。ただし、すべての -1018 エラーがハードウェアの問題または欠陥を示しているわけではありません。
Microsoft では、年間で 100 台の Exchange サーバーあたり 1 回の -1018 エラーの発生率は標準であり、予想の範囲内であると考えています。この "1/100" の許容エラー率は、ハードウェアの信頼性の限界に関する Microsoft の経験に基づいています。
Microsoft IT は、次のいずれかの条件が存在する場合にハードウェアを交換するか、根本的な原因の調査を行います。
| • | -1018 エラーが、システムの問題または欠陥を示す他のエラーまたは状況に関連している。 |
| • | 同じシステムで複数の -1018 エラーが発生した。 |
| • | -1018 エラーが同じ種類の複数のシステムで "1/100" のしきい値を超えて発生し始めた。 |
-1018 エラーが発生するという事実に対しては何も行うことができませんが、エラーの発生は削減できます。100 台の Exchange サーバーあたり年間 1 〜 2 回より高い率で -1018 エラーが発生している場合は、この記事で概説した根本的な原因の分析のアドバイスと実践が役に立つ可能性があります。この問題がそれほど高い率で発生していない場合でも、この記事で提案した復旧方法がより迅速で効果的な復旧に役立つことを願います。
詳細情報
World Wide Web 上の情報については、次のアドレスにアクセスしてください。
http://www.microsoft.com/japan/
http://www.microsoft.com/japan/showcase/
http://www.microsoft.com/japan/technet/itsolutions/msit/default.mspx
このドキュメントに関するご質問、ご意見、またはご提案をお寄せいただく場合、または「How Microsoft Does It」(英語) に関する詳細については、次のアドレスまで電子メールをお送りください。
showcase@microsoft.com (英語のみ)
付録 A: ケース スタディ
この節では、Microsoft、サードパーティ ベンダ、および Exchange を使用している顧客が共同で行った実際の -1018 エラーに関する調査のケース スタディ 2 件について概説します。プライバシー上の理由から、顧客およびベンダの名前は省略しており、これらを特定する詳細情報は変更されています。
これらの調査は、大多数の -1018 エラーの根本的な原因を特定するために必要な典型事項ではありません。どちらかと言うと、ときどき発生する気付きにくく難しいケースを示しています。どちらのケースでも、調査には、共通プラットフォームでの -1018 エラーの傾向付けが不可欠でした。
ケース スタディ 1
運用環境で 100 台近い Exchange サーバーを使用している Exchange の顧客の場合は、少数のサーバーで -1018 エラーがときどき繰り返し発生しました。Exchange にはすべて同じ製造元のサーバーが使用され、サーバーの役割と負荷に応じて 2 つの異なるモデルが使用されていました。エラーは両方のサーバー モデルでランダムに発生するように見えました。
通常の診断テストでは、いずれのサーバーにも問題がないと示されました。あるサーバーで -1018 エラーが発生した場合、別のエラーは数か月間発生しないことがありました。Microsoft の担当者は、一部のサーバーを運用環境から除外し、広範な Jetstress テストを実行することを推奨しました。これらのテストでも、何も明らかにはなりませんでした。サーバーはすべて類似していますが、-1018 の問題が発生したのは少数のサーバー (約 20 %) のみでした。それでもランダム エラーの妥当なしきい値を上回っていたため、サーバー プラットフォームに問題があるようだと考えました。
Microsoft の担当者は、すべてのサーバーで発生した各 -1018 エラーを単一のスプレッドシートで追跡することを推奨しました (詳細については、この記事の「付録 B: -1018 レコードの保持」を参照してください)。この手法により、主観的な印象を裏付けることができ、見逃している可能性のある捕らえにくいパターンをより適切に分析できます。
しばらくすると、17 個のエラーがスプレッドシートに記録され、パターンが現れてきました。-1018 エラーのほとんどは、チェックサムの 28 ビット目が不正でした。28 ビット目でなかった場合は、23 ビット目または 32 ビット目でした。
Exchange チェックサムの特性の 1 つは、ページで発生したエラーが単一ビット エラー (ビット フリップ) の場合、ページ上のチェックサムも、ページ上に存在する必要のあるチェックサムと 1 ビットのみ異なるということです。
たとえば、次の特性のある -1018 エラーがレポートされたと想定します。
| • | 予期されたチェックサム (実際にページにあるチェックサム): 39196aa6 |
| • | 実際のチェックサム (ページの読み取り時に計算されたチェックサム): 38196aa6 |
チェックサムは、Exchange ページにリトル エンディアン形式で格納されます。このため、ページ上の実際のチェックサムは、8 桁のチェックサムを構成する 4 バイトの順序を反転して得られます。
| • | 数値 51 79 f5 33 は 33 f5 79 51 になります。 |
| • | 数値 41 79 f5 33 は 33 f5 79 41 になります。 |
2 つのチェックサムが単一ビットを除いて一致するかどうかを判断するには、これらをバイナリに変換し、XOR 論理演算子を使用する必要があります。XOR 演算子は、一方のチェックサムの各ビットを、もう一方のチェックサムの対応するビットと比較します。ビットが同じ場合 (両方とも 0 または両方とも 1)、XOR の結果は 0 です。ビットが異なる場合、XOR の結果は 1 です。したがって、2 つの数値間の単一ビットが異なる場合、XOR の結果は単一ビットのみが 1 になります。ページ上の複数のビットが変更された場合、チェックサムの XOR の結果は複数のビットが 1 になります。これを表 1 に示します。
| チェックサム | 16 進数 | バイナリ |
予期されるチェックサム | 51 79 f5 33 | 00110011 11110101 01111001 01010001 |
実際のチェックサム | 41 79 f5 33 | 00110011 11110101 01111001 01000001 |
XOR の結果 | XOR の結果 | 00000000 00000000 00000000 00010000 |
表 1. チェックサムの XOR 分析
多くの場合、-1018 破損のパターンは、ハードウェア ベンダがわかりにくい問題を特定する際の貴重な手がかりになります。チェックサムの不一致のログと共に、直接分析のための実際の損傷ページのダンプも役立ちます (詳細については、この記事の「付録 B: -1018 レコードの保持」を参照してください)。
最終的にサーバーでは、問題が短時間の間に複数回発生したことが検出されました。Jetstress テストでは、新しい -1018 エラーを一貫して作成することができ、ほぼ必ずチェックサムの 28 ビット目が変更されていることを示していました。サーバーは、分析のために Microsoft に送られました。ストレス テストと診断を Microsoft と製造元の両方で何週間も実行したにもかかわらず、エラーは再現できませんでした。
一方、顧客は、Exchange サーバーだけでなく Active Directory ドメイン コントローラでも -1018 エラーが発生し始めたことに気付きました。Active Directory データベースは Exchange データベースと同じエンジンをベースとしており、ここでも -1018 エラーを検出してレポートします。
ハードウェア リセット カードを使用してサーバーをリモートで再起動した後に、Active Directory サーバーでエラーが発生しているようであることがわかりました。Microsoft の調査担当者は、テスト サーバーを同じ方法で再起動することを試し、ついに問題の再現に成功しました。
この時点では、リセット カードが最も疑わしいと思われました。しかし、エラーはカードを使用して再起動するたびに発生するわけではなく、ほとんどの場合、問題はありませんでした。長時間の Jetstress の実行がエラーなく完了した後、突然すべての Jetstress の実行が順番に失敗しました。
最終的に、そのカードで約 7 回再起動するたびに問題が再現することが明らかになりました。問題はカードの欠陥ではなく、カードがサーバーの完全なコールド リスタートを実行し、電源リセットをシミュレートしていたという事実でした。
コールド リスタートを 7 回実行するたびに、サーバーは不安定になりました。この状態は、ウォーム リスタートから次のコールド リスタートまで続き、その時点でさらに 6 回のコールド リスタートが行われるまでサーバーは再び安定します。
顧客の組織の運用環境では、両方のサーバー モデルで同じ部品番号のまったく同じサーバー コンポーネントを使用していました。しかし、この問題が生じるのは製造されるコンポーネントの 20 % のみであったため、原因をコンポーネントの欠陥に特定するのがはるかに難しくなっていたのです。
ケース スタディ 2
250 台の Exchange サーバーを使用している大規模な Exchange の顧客が、複数のサーバーおよび複数の SAN ディスク システムでの頻繁な -1018 エラーに悩まされていました。全面的な -1018 復旧を行わずに 1 週間が過ぎることはめったにありませんでした。
-1018 エラーの発生後、大量のデータ損失が複数回発生していました。あるケースでは、バックアップ監視が行われていませんでした。最新の Exchange バックアップは上書きされ、その後のバックアップは成功しませんでした。1 か月後、サーバーで致命的なエラーが発生し、データベースが復旧されませんでした。すべてのユーザーのメールが失われました。別のケースでは、最初の -1018 エラーによってデータベースの数 10 万ページが破損し、トランザクション ログ ドライブも影響を受けました。問題を悪化させた要因として、このサーバーではバックアップも怠っていました。最新のバックアップは数週間前のものであったため、それ以降のすべてのメールが失われました。
Microsoft 製品サポート サービスがこの数か月間に何度も呼ばれ、それぞれの問題後のデータ復旧にほぼ成功しました。しかし、これらの各ケースでは、個々のサーバー オペレータと製品サポート サービス エンジニアが関与し、復旧を分担して作業しましたが、すべてのサーバーでの根本的な原因の分析には重点を置いていませんでした。
データ損失のケースは、Microsoft アカウント チームと Exchange の顧客の管理職の双方の注意を引きました。Microsoft が各ケースの関連付けと問題の回避に関する詳細の質問を開始すると、-1018 エラーの発生率が標準しきい値をはるかに上回っていることがすぐに明らかになりました。
過去の問題に関する情報は、ほとんどが入手不能または不完全でした。しかし、Microsoft では、新しい各問題を追跡するためのスプレッドシートを作成しました。スプレッドシートはすぐにいっぱいになり、パターンが現れ始めました。問題は、単一のパターンがなく、複数のパターンがあることでした。
いくつかのケースでは、チェックサムの下位 2 バイトが変更されていました。これで先行きが明るくなったように思われましたが、ビット 29 と 30 が不正で、他に共通点のないエラーがいくつか発生しました。その後、チェックサムまたは損傷ページに認識できるパターンのない大規模なチェックサム不一致があるエラーが突発的に発生しました。一部のサーバーには、複数の不良ページがありました。一時的な -1018 エラーが頻繁に発生し、データベース全体のチェックサムで、連続した実行での異なるエラーが頻繁に現れました。
調査と解決にはほぼ 1 年かかりました。時間がたつにつれ、一部のサーバーとディスク フレームでは他のサーバーやディスク フレームよりも問題が発生しやすく、これは組織のすべての Exchange サーバーの一般的な問題ではないことが明らかになってきました。その年に、次の問題が -1018 エラーの根本的な原因であることが発見されました。
| • | サーバー オペレータが、I/O アトミック性の保証のないディスク コントローラでサーバーを過度に使用していた。 |
| • | 論理装置番号 (LUN) マスキングのない SAN により、複数のサーバーが単一のディスクを同時に制御できたため、ディスクが破損した。 |
| • | データ破損の原因になることが知られていたバージョンを含む、非常に古いファームウェア リビジョンが使用されていた。 |
| • | クラスタ システムが Windows Hardware Quality Labs (WHQL) の認定を受けていなかった。これらのクラスタには、クラスタ状態の遷移中にディスク I/O を処理できないディスク コントローラがありました。 |
| • | ウイルス対策アプリケーションが、Exchange データ ファイルを正しく除外するように構成されていなかった。これは、Exchange ファイルおよびプロセスの突然の検疫、削除、または変更の原因となっていました。汎用ファイル スキャニング ウイルス対策プログラムは、Exchange データベースで使用できません。多くのベンダでは、Microsoft Exchange ウイルス対策 API を実装する効果的な Exchange 対応スキャナが用意されています。 |
| • | ベンダ ハードウェアのバグが、少数のエラーの原因となっていた。 |
| • | 有効期間を超えていたハードウェアの経年変化と漸進的な劣化が、明白な問題の原因となっていた。 |
-1018 エラーの根本的な原因の修正は、困難ですが最終的には価値のあるプロセスでした。ハードウェアと構成に対する変更だけでなく、運用の改善も必要でした。組織では、-1018 エラーの発生の大幅な削減に成功しただけでなく、効果的な監視および復旧手順を実装することで、各エラーがエンド ユーザーに与える影響が大幅に低減しました。
このケース スタディは、ケース スタディ 1 と対照的です。ケース スタディ 1 では、不可解で捕らえにくいハードウェア バグがすべての問題の単一の根本原因でした。ただし、ほとんどの Exchange 管理者にとって、-1018 エラーを削減および管理するための秘訣は、通常の運用改善を実装することです。ほとんどの場合、組織全体で -1018 エラーを追跡することで明らかになるパターンは、防ぐ必要のある明白なエラーと問題を指摘します。ケース スタディ 1 の方が興味深い事例ですが典型的ではなく、ケース スタディ 2 は、Exchange を使用する複数の組織が -1018 エラーの制御と削減のために実行したプロセスの代表です。
付録 B: -1018 レコードの保持
-1018 エラーの大多数では、根本的な原因は別の関連するエラーや障害によって示されます。原因がそれほど明らかでないエラーの場合、複数のサーバーで長時間 -1018 エラーを追跡することは根本的な原因の特定に不可欠です。
根本的な原因を簡単に判別できるエラーの場合でも、-1018 エラーの継続的な追跡には価値があります。エラーが組織にどのように影響するか、および運用やその他のどの部分を改善すればエラーの影響を低減できるかがわかります。
データベースのエラーをスプレッドシートや単純なテキスト ファイルを使用して追跡することが必要な場合があります。Microsoft では、Microsoft Office Excel 2003 スプレッドシートを使用しています。次のフィールドの一覧をニーズや希望に合わせて、詳細情報を追跡できます。
要点
次のファイルを -1018 エラーごとに必ず保存する必要があります。
| • | -1018 エラーがレポートされた時点から最後の正常なバックアップまでのブックエンド期間についてのアプリケーション ログおよびシステム ログ |
| • | ページ ダンプ |
Eseutil ページ ダンプ
この Eseutil 機能は、ページ上の重要なヘッダー フィールドの内容を示します。このコマンドには、論理ページ番号が必要です。この記事の「ページ順序」の説明に従って、エラーの説明から論理ページ番号を計算できます。
たとえば、データベース ファイル Priv1.edb の論理ページ 578 が損傷している場合は、次のコマンドを使用してファイル 578.txt にページをダンプできます。
Eseutil.exe /M priv1.edb /P578 ≥ 578.txt
/P スイッチとページ番号の間には空白文字がないことに注意してください。
このコマンドの出力は、次のようになります。
Microsoft(R) Exchange Server Database Utilities
Version 6.5
Copyright (C) Microsoft Corporation.All Rights Reserved.
Initiating FILE DUMP mode...
Database: priv1.edb
Page: 578
checksum <0x03300000, 8>: 2484937984258 (0x0000024291d88902)
expected checksum = 0x0000024291d88902
****** checksum mismatch ******
actual checksum = 0x00de00de91d889fd
new checksum format
expected ECC checksum = 0x00000242
actual ECC checksum = 0x00de00de
expected XOR checksum = 0x91d88902
actual XOR checksum = 0x91d889fd
checksum error is NOT correctable
dbtimeDirtied <0x03300008, 8>: 12701 (0x000000000000319d)
pgnoPrev <0x03300010, 4>: 577 (0x00000241)
pgnoNext <0x03300014, 4>: 579 (0x00000243)
objidFDP <0x03300018, 4>: 114 (0x00000072)
cbFree <0x0330001C, 2>: 6 (0x0006)
cbUncommittedFree <0x0330001E, 2>: 0 (0x0000)
ibMicFree <0x03300020, 2>: 4038 (0x0fc6)
itagMicFree <0x03300022, 2>: 3 (0x0003)
fFlags <0x03300024, 4>: 10370 (0x00002882)
Leaf page
Primary page
Long Value page
New record format
New checksum format
TAG 0 cb:0x0000 ib:0x0000 offset:0x0028-0x0027 flags:0x0000
TAG 1 cb:0x000e ib:0x0000 offset:0x0028-0x0035 flags:0x0001 (v)
TAG 2 cb:0x0fb8 ib:0x000e offset:0x0036-0x0fed flags:0x0001 (v)
ダンプにチェックサムの不一致が見られない場合でも、-1018 エラーが一時的なものであることを意味しているとは限りません。論理ページ番号の計算を間違った可能性があります。演算をもう一度チェックし、ダンプしたページに -1018 エラーがない場合は前のページと次のページもダンプすることをお勧めします。データベース全体に対して Eseutil /K を実行することも、追加のチェックになります。
必要なエラー情報
-1018 が発生するたびに、次の項目を必ずログに記録する必要があります。
| • | アプリケーション ログの -1018 イベント情報: |
| • | 日付と時刻 |
| • | サーバー名 |
| • | イベント ID |
| • | イベントの説明 |
| • | クラスタの場合は、エラーが発生したクラスタ ノード |
| • | サーバーのメーカーとモデル |
| • | ストレージの種類: |
| • | 直接アクセス記憶装置 (DASD) |
| • | ファイバ チャネル ストレージ エリア ネットワーク (SAN) |
| • | Internet Small Computer System Interface (iSCSI) SAN |
| • | ネットワークに接続されているストレージ |
| • | ストレージのメーカーとモデル: |
| • | ディスク コントローラ |
| • | 複数パス構成 |
| • | イベント、ログ、およびダンプ ファイル用の永続的な場所または共有 |
追加情報
-1018 が発生した場合は、次の項目も記録できます。
| • | ブックエンド期間の例外事項: |
| • | 再起動 |
| • | クラスタの移行 |
| • | ディスク エラー |
| • | メモリ エラー |
| • | その他 |
| • | ファイル オフセット |
| • | 論理ページ番号 (バイト オフセットから計算) |
| • | 実際のチェックサム (実行時に計算) |
| • | 予期されるチェックサム (ページから読み取り) |
| • | 実際のバイナリ チェックサム |
| • | 予期されるバイナリ チェックサム |
| • | チェックサムの XOR 結果 |
| • | 検出方法 (実行時、マウントの問題、またはバックアップの問題) |
| • | サーバーが使用不能か使用可能か |
| • | 最後の正常なバックアップ時刻 |
| • | Eseutil /m /p /k などで確認されたエラー |
| • | 永続的なエラーか一時的なエラーか |
| • | ファイルの場所 (Eseutil および Esefile ページ ダンプ、生のページ ダンプ、MPSReport) |
| • | サーバー ハードウェア |
| • | サーバー BIOS |
| • | コントローラ |
| • | コントローラのファームウェア リビジョン |
| • | ストレージ |
| • | 影響 (影響を受けるデータベース) |
| • | 復旧のダウンタイム |
| • | 復旧戦略 |
| • | 根本的な原因 |
| • | コメント |
| • | 入力担当者 |
Excel 用の XOR 計算のサンプル
付録 A では、チェックサムを比較してパターンを探す方法を説明しました。次に示す Microsoft Office Excel の計算式を使用して、この比較を自動化できます。必要な機能を使用可能にするには、Excel 用の分析ツールをインストールする必要があります。分析ツールは、Excel の [ツール] メニューの [アドイン] からインストールできます。
16 進数のチェックサムをバイナリに変換する
次の計算式を Excel のセルにコピーします。この計算式では、16 進数のチェックサムがセル A1 にあることを想定しています。16 進数のチェックサムが別のセルにある場合は、計算式の A1 を参照している部分をそれぞれ実際のセルを表すように変更します。計算式の改行は無視してください。この計算式は Excel で 1 行に入力します。
=CONCATENATE(HEX2BIN(MID(A1,7