データベース回復戦略
ここでは、データベース構造とデータベース回復戦略について説明します。
データベース構造について
データベースの構造を理解するには、データベースのページ レベル、Exchange Store Engine (ESE) テーブル レベル、およびアプリケーション レベルを理解する必要があります。これらの各レベルについて、以下に簡単に説明します。
ページ レベル : ファイルには、順序付けられた一連のページ (通常は 4 KB または 4 KB の整数倍) が含まれており、各ページは共通の編成構造を共有しています。各ページには、ページ ヘッダー情報とページ データが含まれています。ヘッダー情報には、Exchange がデータの整合性を検証したり、ページのシングルビット エラーを訂正したりするために使用できる、そのページのチェックサムが含まれています。
ESE テーブル レベル : ページのグループは、ESE データベース エンジンによって管理されるテーブルによって所有されます。標準的な Exchange データベースには、数千の個々のテーブルが含まれています。
アプリケーション レベル : ESE は、さまざまなアプリケーションで使用できる汎用データベースです。たとえば、Exchange と Active Directory ディレクトリ サービスはどちらも ESE を使用します。ESE データベース エンジンは、情報を特定のアプリケーションから指示されたとおりにテーブルに格納します。ESE 自体は、アプリケーションによって定義されたテーブル間の関係や、各テーブルに格納されているデータの意味を認識していません。
データベース回復戦略について
データベース ファイルの破損から回復するための最も基本的な戦略は、データベースの正常なコピーをバックアップから復元し、バックアップ以降に生成されたトランザクション ログ ファイルを使用してデータベースをロール フォワードすることです。この戦略を使用するには、次の 3 つの前提条件が満たされている必要があります。
- データベースの正常なバックアップが存在すること。
- バックアップ以降に生成されたすべてのトランザクション ログ ファイルが使用可能であり、破損していないこと。
- データベース内の問題が、論理的な破損や、予期しない削除によるものではないこと。たとえば、ウイルス検出プログラムがメッセージを破損させたり削除したりした場合は、その破損や削除がトランザクション ログ レコードの一部になり、バックアップからの復元後にデータベースに再生されます。
その他のデータベース回復戦略を以下に示します。
メールボックスの移動
Exchange メールボックスを別のデータベースに移動すると、そのメールボックスの内容は、作成されたときと同じように Exchange インフォメーション ストアによって処理されます。破損しているアイテムはスキップされます。このため、すべてのメールボックスを新しいデータベースに移動する方法は、破損したアイテムを削除すると同時に、復旧されるユーザー コンテンツの量を最大化するための優れた戦略です。
メールボックスが移動されると、Outlook クライアント プロファイルは、クライアントがその新しいデータベースまたはサーバーを参照するように自動的に更新されます。この更新が正常に行われるには、すべてのクライアントが一度ログオンしてリダイレクトされるまで、以前のサーバーが、実行中のインフォメーション ストア サービスと共にオンライン状態を保つ必要があります。以前のサーバーのオンライン状態が保たれていない場合は、Outlook クライアント プロファイルを手動で、またはスクリプトを介して更新する必要があります。
以前のオフラインまたはキャッシュ モードのクライアント ファイルは、メールボックスが移動された後も引き続き動作します。また、メールボックスを移動したとき、クライアント ルール機能も保持されます。
メールボックスの移動は、移動先のサーバーに、メールボックス内のすべてのアイテムを一度に再配信した場合と同じ結果をもたらします。そのため、多数のメールボックスを移動する場合は、ピーク時間を避けて操作を実行すること、およびクライアントには前もって移動が実行される時間や、移動後のログオン時に問題が発生した場合の問合わせ方法に関する情報を提供しておくことをお勧めします。
多くのメールボックスを移動すると、移動先のデータベースに対して生成されるデータベース トランザクション ログ ファイルの数が通常よりも増えます。メールボックスの一括移動操作中、移動先のサーバーのトランザクション ログ ディスク領域を注意深く監視する必要があります。トランザクション ログ ディスク領域が不足しそうなときは、オンラインでの完全または増分バックアップを実行してログ ファイルをクリアするか、または移動前に循環ログを有効にし、移動後すぐに無効にすることができます。
すべてのメールボックスを新しいデータベースに移動し、以前のデータベースを破棄すると、復旧可能なユーザー コンテンツの保持が最大化されると同時に、データベースのダウンタイムが最小限に抑えられます。
Exchange データベースを別のサーバーまたはストレージ グループに移動する方法の詳細については、「別のサーバーまたはストレージ グループへの Exchange メールボックス データベースの移動」を参照してください。
データベースの修復
一般に、データベースの修復は、データベースの復元およびロール フォワードが実行不可能な場合にのみ行ってください。多くの場合、データベースの修復はバックアップからの復元に比べて長い時間がかかります。
注 データベースの破損が深刻な場合は、修復にさらに長い時間がかかり、修復が成功する確率は低くなります。標準的なエンタープライズ クラスのサーバー ハードウェアを使用して、破損していないか、またはわずかしか破損していないデータベースに対して修復を実行した場合、その処理には通常、5 GB のデータあたり約 1 時間かかります。サービス レベル契約 (SLA) の設計の一部として修復時間を計算している場合は、組織内の Exchange に使用されるものとほぼ同等のハードウェア上で実行されている標準的なデータベースに対して独自のベンチマークを実行する必要があります。データベースの破損が深刻な場合は、修復時間が 10 倍以上になる可能性があります。
Eseutil を使用してデータベースを修復する方法の詳細については、「Eseutil /P 修復モード」を参照してください。
復元、修復、および結合
データベースの復元、修復、および結合は一般に、複合型の戦略と呼ばれます。この戦略は、データベースの正常なバックアップはあるが、バックアップ後に作成された一部のトランザクション ログが存在しない場合に使用できます。
この場合は、バックアップを復元し、それと並行して、同じサーバーまたはラボ サーバー上の回復用ストレージ グループでデータベースの破損したコピーを修復することができます。次に、回復用ストレージ グループの機能を使用して、データベースの両方のコピーを個別にマウントし、修復されたデータベースのデータを復元されたデータベースに結合することができます。
修復が正常に完了すると想定した場合、この戦略には、トランザクション ログを使用できる場合とほぼ同じ量のデータを回復できる可能性があります。回復用ストレージ グループを使用したいくつかの複合型の戦略の詳細については、Exchange Server 2003 の回復用ストレージ グループの使用についてのページ (https://go.microsoft.com/fwlink/?LinkId=47589) を参照してください (このサイトは英語の場合があります)。
詳細情報
詳細については、『Exchange Server データベース ユーティリティ ガイド』の以下のトピックを参照してください。