Exchange Server データベース アーキテクチャとデータベース エンジンについて

文書翻訳 文書翻訳
文書番号: 271987 - 対象製品
すべて展開する | すべて折りたたむ

目次

概要

この資料では、Microsoft Exchange Server のデータベース アーキテクチャおよびデータベース エンジンの概要について説明します。データベース コンポーネント、データベースの整合性の保守、発生する可能性のあるデータベース障害、およびデータベース ユーティリティに関する情報も提供します。

詳細

Exchange Server では、フォールト トレラントなトランザクション ベースのデータベースを使用して、データベースに反映される前のメッセージやディレクトリ情報を格納します。Exchange Server 5.5 Standard Edition の各データベースの最大サイズは 16 GB です。Exchange Server 5.5 Enterprise Edition では、各データベースの最大サイズには制限がなく、使用しているハードウェアにより最大サイズが決まります。

電源異常やその他のシステム障害が発生した場合、Exchange Server では、トランザクション ログ ファイルを使用することにより、既にサーバーで受け付けていて、データベースに書き込まれていなかったデータを再構築します。

データベース コンポーネント

Exchange Server は、標準的なデータベース テクノロジに基づいて設計されています。Exchange Server システムでは、組み込みのデータベース エンジンを使用して、Exchange Server のディスク構造の配置と、メモリの管理を行います。このデータベース エンジン テクノロジは、WINS (Windows インターネット ネーム サービス) や DHCP (Dynamic Host Configuration Protocol) など、他の Windows アプリケーションでも使用されています。

インフォメーション ストア

インフォメーション ストアは、Exchange Server のデータベース管理における主要なコンポーネントで、実際は 2 つの異なるデータベースで構成されています。プライベート インフォメーション ストア データベース (Priv.edb) では、ユーザーのメールボックスを管理します。パブリック インフォメーション ストア データベース (Pub.edb) では、パブリック フォルダのデータを管理します。

インフォメーション ストアは、MAPI (Messaging Application Programming Interface) およびデータベース エンジンと連動して、すべてのユーザー操作が確実にサーバーのハード ディスクに記録されるようにします。たとえば、ユーザーが Microsoft Outlook でメッセージを保存すると、まず MAPI によりインフォメーション ストアが呼び出され、インフォメーション ストアによってデータベース エンジンが呼び出されます。そして、データベース エンジンにより、変更内容がディスクに書き込まれます。

JET データベース エンジン

Exchange Server データベースは、JET 形式のデータベースです。この形式のデータベースでは、ログ ファイルを使用して情報の追跡および管理を行います。Microsoft JET は、トランザクション ベースの処理機能を強化するための、高度な機能だけでなく速度とパフォーマンスを兼ね備えた、高性能な 32 ビットのマルチスレッド データベース エンジンです。

このデータベース エンジンは、メモリ内で 4 KB 単位のページ データの入れ替えを行い、ディスクの内容をメモリにキャッシュします。メモリ内のページを更新し、新しいページまたは更新されたページをディスクに書き込みます。データベース エンジンでは、要求を受信すると、継続的にディスクに書き込むのではなく、メモリにデータをバッファするため、システムのパフォーマンスが向上します。

Exchange Server 5.5 以前のバージョンでは、バッファ キャッシュのサイズは固定されています。固定サイズを上回るメモリが必要な場合は、管理者が手動でバッファ サイズを変更する必要があります。

Exchange Server 5.5 では、バッファを動的に割り当てることにより、使用できるメモリ量および Microsoft Windows NT Server コンピュータで実行中の他のサービスで使用されているリソースに応じて、バッファ キャッシュのサイズを拡大または縮小できるようになりました。他のサービスでメモリを使用していない場合、Exchange Server データベース エンジンでは、必要なだけメモリを使用できます。他のサービスでメモリを使用する必要がある場合は、データベース エンジンは、ページをハード ディスクに保存し、バッファ サイズを縮小して、一部のメモリを解放します。

ユーザーから要求があると、データベース エンジンは要求をメモリに読み込み、そのページに "ダーティ" というマークを設定します ("ダーティ" ページとは、データが書き込まれた状態でメモリ内に保持されているページです)。これらのダーティ ページのデータは、後でディスク上にあるインフォメーション ストア データベースに書き込まれます。

データベースの整合性の保守

メモリにデータをキャッシュする方法は、最も効率の良いデータ処理方法ですが、ディスク上のデータが完全に最新の状態にならないという 1 つの問題があります。メモリ内にダーティ ページが存在するため、Exchange Server が正常に実行されていても、データベースに不整合のフラグが設定されます。シャットダウン中にすべてのダーティ ページのデータがディスクに正常に転送され、エラーが発生しなかった場合にのみ、データベースは整合性が取れた状態になります。

メモリ内の情報が失われた場合、たとえば、メモリ内のデータがディスクに書き込まれる前にサーバーがクラッシュして、データベースの整合性が損なわれた場合について考えます。このような場合、Exchange Server の復旧には、トランザクション ログ ファイルが使用されます。

トランザクション ログ ファイル

トランザクション ログ ファイルには、メモリ内の揮発性データの信頼できるコピーが保持されています。システムがクラッシュしても、データベースが破損していない場合は、トランザクション ログ ファイルを使用することで、クラッシュする直前にコミットされたトランザクションの状態にデータを回復できます (ディスク障害の影響を受けてデータベースが破損することがないように、トランザクション ログ ファイルは専用のハード ディスクに保存することをお勧めします)。

Exchange Server は "トランザクション ベース" のメッセージング システムであり、インフォメーション ストアはトランザクション データベースです。トランザクションとは、挿入、削除、および更新など、データベースに対して行われた一連の変更です。システムでは、トランザクションごとに ACID プロパティと呼ばれる 4 つの特性が維持されます。
  • 原子性 (Atomic) : すべての操作が実行されるか、(実行不能な場合は) すべての操作が実行されないか、そのいずれかの状態のみを取ります。
  • 一貫性 (Consistent) : データベースは、変更前も変更後も正しい状態を保ちます。
  • 分離性 (Isolated) : コミットされるまで、変更内容はトランザクションの外部に公開されません。
  • 持続性 (Durable) : コミットされたトランザクションは、システムがクラッシュしても、データベース内に保持されます。
これらの特性が維持されているということは、データに持続性または一貫性があり、クラッシュや障害から保護されていることが保証されている場合にのみ、データベース エンジンでトランザクションがコミットされる、ということです。データベース エンジンは、メモリからハード ディスク上のトランザクション ログ ファイルへのデータの転送が完了した場合にのみデータをコミットします。

たとえば、[受信トレイ] フォルダから [Important] フォルダにメッセージを移動する場合、Exchange Server では以下の 3 つの処理が実行されます。
  1. [受信トレイ] フォルダからメッセージを削除します。
  2. [Important] フォルダにメッセージを挿入します。
  3. 各フォルダに関する情報を更新して、フォルダ内のアイテム数と未読アイテムの数に反映させます。
これらの処理は 1 つのトランザクションで行われます。処理の順序は、重要ではありません。メッセージが [Important] フォルダに挿入されるまで、メッセージの削除はコミットされないため、[受信トレイ] フォルダからのメッセージの削除は安全に実行されます。システムがクラッシュしても、メッセージが移動処理中に失われることや、同じメッセージが 2 つ存在するようなことはありません。

論理的には、データはメモリからログ ファイルに移動され、その後ディスク上にあるデータベースに移動されるという考え方ですが、実際には、データはメモリからディスク上にあるデータベースに移動されます。ログ ファイルは書き込みを高速化するために最適化されていて、通常の処理では、データベース エンジンからログ ファイル データの読み取りが行われることはありません。データベース エンジンでは、インフォメーション ストア サービスが異常終了またはクラッシュした場合にのみ、ログ ファイルを再生してデータを回復するために、ログ ファイルからデータの読み取りを行います。

チェックポイント ファイル

データベース エンジンは、ディスク上のデータベース ファイルに書き込まれていないデータを追跡できるように、連続したログ ファイルごとに Edb.chk という名前のチェックポイント ファイルを保持します。チェックポイント ファイルは、一連のログ内の場所を指すポインタで、障害発生時にインフォメーション ストアがデータの復元をするための開始位置を示します。チェックポイント ファイルは、効率的な回復を行うのに重要なファイルです。チェックポイント ファイルがないと、インフォメーション ストアは、ディスク上にある最も古いログ ファイルの先頭から、各ログ ファイルのすべてのページについて、ページのデータが既にデータベースに書き込まれているかどうかを確認する必要があります。単にデータベースの整合性を取ることが目的の場合、これは時間的に効率の悪い作業です。

チェックポイント ファイルは、システム ディスク上にあります。システム ディスクを回復する必要がある場合、チェックポイント ファイルが存在しないか、または無効なバージョンのチェックポイント ファイルしか存在しない可能性があります。ただし、ほとんどの場合、チェックポイント ファイルでは、チェックポイント ファイル自体も管理されています。

通常のログ出力

次の手順は、データがトランザクション ログ ファイルに書き込まれる "通常のログ出力" の処理を示しています。
  1. ユーザーがメッセージを送信します。
  2. MAPI によってインフォメーション ストアが呼び出され、ユーザーがメッセージを送信したことがインフォメーション ストアに通知されます。
  3. インフォメーション ストアにより、データベース エンジンでトランザクションが開始され、対応する変更がデータに加えられます。
  4. データベース エンジンにより、メモリ内の新しいページにデータが書き込まれ、メモリにトランザクションが記録されます。
  5. 同時に、データベース エンジンにより、トランザクション ログ ファイルにトランザクションが保存され、ログ レコードが作成されます。トランザクション ログ ファイルの末尾に到達すると、ロールオーバーが実行され、一連のログ ファイルに新しいログ ファイルが作成されます。
  6. データベース エンジンにより、ハード ディスク上にあるデータベース ファイルにダーティ ページのデータが書き込まれます。
  7. チェックポイント ファイルが更新されます。
循環ログ

Exchange Server では、循環ログという機能がサポートされています。これは、管理者がデータの回復よりもディスク容量を重視していた時期に実装された機能です。

循環ログは、通常のログ出力と同様に機能します。ただし、ディスクに転送された情報を追跡するのにチェックポイント ファイルが不可欠であるという点が異なります。循環ログを有効にしている場合、チェックポイント ファイルが次のログ ファイルに移動すると、古いログ ファイルが再利用されます。この処理が行われると、ディスク上にあるログ ファイルをバックアップ メディアと併せて使用しても、最後にコミットしたトランザクションの状態を復元することはできません。

Exchange Server 5.5 では、ログ ファイルを一定のサイズに維持し、サイズが大きくなることを防ぐために、デフォルトで循環ログが有効になっています。ログ ファイルのサイズが 5 MB の制限値に達すると、データベース エンジンによりログ ファイルが削除され、それに続く新しいログ ファイルが作成されます。そのため、Exchange Server では、クラッシュが発生した場合に、データベースの整合性を保つのに必要最低限のデータのみがハード ディスク上に保存されます。

Exchange Server コンピュータでは循環ログを無効にすることをお勧めします。循環ログを有効にすると、ディスク領域の使用量を抑えられますが、過去にさかのぼって障害が発生する直前にコミットされたトランザクションの状態まで復元することはできません。ログ ファイルを再生できないため、復元できるのは、最後に実行した完全バックアップの状態までです。1 つでもログ ファイルが上書きされると、ログ ファイルに記録されている残り 99% のデータを復元する方法はありません。

つまり、循環ログを有効にすると、トランザクション ベースのシステムの利点が損なわれます。データが必要ない場合、またはデータを復元する手段が他にある場合にのみ、循環ログを有効にする意味があります。ログ ファイルにより消費されているディスク リソースの量を減らすには、定期的にオンライン バックアップを実行してログ ファイルをクリーン アップすることをお勧めします。バックアップを実行すると、不要なトランザクション ログ ファイルは自動的に削除されます。

データの保護

データベース ファイルはデータの回復において最も重要な要素であると考えるのが普通ですが、トランザクション ログ ファイルにはデータベース ファイルに含まれていない情報が含まれているため、Exchange Server で、より重要性が高いのはトランザクション ログ ファイルです (そのため、トランザクション ログ ファイルは安定したサーバーに配置し、データベース ファイルを処理速度の遅いディスクに配置する結果になっても、トランザクション ログ ファイルを専用の高性能なディスクに配置することをお勧めします)。

トランザクション ログ ファイルには、障害が発生したときに、システムを回復できるように、メモリ内にある揮発性データのコピーが保持されています。ログ ファイルを保持していれば、システムがクラッシュしても、データベースが破損していない限り、障害が発生する直前にコミットされたトランザクションの状態までデータを回復できます。

また、データベースにページを挿入するよりも、ログ ファイルにページを順に追加する方が処理が早いため、トランザクション ログ ファイルを使用することでデータの書き込みの効率が向上します。データベースに変更が加えられると、データベース エンジンによりメモリ内のデータが更新されます。同時に、システムで障害が発生した場合にトランザクションを再実行する方法を記録しておくために、ログ ファイルにもトランザクションのレコードが書き込まれます。その後、データベース エンジンにより、ディスク上のデータベースにデータが書き込まれます。ディスクへの入出力を最小限に抑えるため、データベース エンジンではバッチ処理でページの転送が行われます。

一連の各ログ ファイルには、最大で 5 MB のデータを記録できます。ログ ファイルがいっぱいになると、ログ ファイルは前回のログ ファイルとして名前が変更され、Edb.log という名前の新しいログ ファイルが作成されます。Exchange Server により、各ログ ファイルに 16 進数の世代番号が割り当てられます。ログ ファイルには同じ名前を使用できるため、データベース エンジンでは、一連の各ログ ファイルのヘッダーに一意な署名を追加して、世代の異なるログ ファイルを識別できるようにしています。

データベースの破損

Exchange Server では、ハードウェアの故障など、障害が発生して、システムを整合性の取れた状態に復元することが必要になる場合があります。現象の異なるさまざまな種類のデータベース障害があるため、問題の診断および修正には、さまざまなツールや技術が必要です。

データベースの障害には、次の 2 種類があります。
  • 物理的な破損
    最も低レベルの破損としては、ディスク上のデータの物理的な破損が挙げられます。通常、このようなデータの破損は、ハードウェアの問題によるもので、バックアップからデータを復元する必要があります。
  • 論理的な破損
    通常、論理的な破損は、データベース レベルで発生します。たとえば、データベース エンジンで発生したエラーが原因で、インデックス エントリに対応する値が存在しない場合があります。論理的な破損は、アプリケーション レベル (メールボックス、メッセージ、フォルダ、添付ファイルなど) で発生することもあります。たとえば、アプリケーション レベルの破損が原因で、参照カウントやアクセス制御レベルに誤りが発生することや、メッセージ本文のないメッセージ ヘッダーが発生することがあります。

物理的な破損

物理的な破損では、データが破壊されることがあり、バックアップから Exchange Server を復元する以外に対応方法がないため、この破損は深刻です。物理的な破損については、早い段階で発見し、迅速に対処することが重要です。

物理的な破損の検出

インフォメーション ストアで物理的な破損が発生すると、イベント ビューアのアプリケーション ログに以下のエラーが出力されます。
  • -1018 (JET_errReadVerifyFailure)

    ディスクから読み取ったデータが、ディスクに書き込まれたデータと同じではありません。
  • -1022 (JET_errDiskIO)

    ハードウェア、デバイス ドライバ、またはオペレーティング システムがエラーを返しました。
  • -510 (JET_errLogWriteFail)

    ログ ファイルのディスク領域が不足しているか、あるいはログ ファイルのディスクにハードウェア障害が存在します。
通常、物理的な破損が発生すると、Exchange Server により -1018 または -1022 エラー メッセージが出力されますが、オンライン バックアップを実行することでも物理的な破損を検出できます。データのバックアップには、オンライン バックアップを使用することをお勧めします。また、オンライン バックアップは、データベースのすべてのページを 1 ページずつ体系的にチェックする唯一の処理であるため、データベース ファイルの破損を検出するのに最適な方法でもあります。

オンライン バックアップを実行すると、Windows NT バックアップ ソフトウェアにより、データベース内の 4 KB 単位のページが読み込まれ、ページがデータベース エンジンに渡され、その後、テープに書き込まれます。データベース エンジンでは、各ページに設定されているチェックサムが正しいかどうかが確認されます。ページに設定されているチェックサムがデータベース エンジンで計算されたチェックサムと一致しない場合、ハード ディスク上のデータベースに物理的な破損があり、NT バックアップにより -1018 エラーがログに出力されます。

物理的な破損の防止

物理的な破損を防ぐ最も良い方法は、サーバーに高品質なハードウェア コンポーネントを搭載し、システムを適切に構成することです。Exchange Server を実行しているコンピュータのデータベースやログ ファイルに対して、ウイルス対策ソフトウェアなど、ファイル レベルのユーティリティを実行しないようにします。

信頼性の高いハードウェアを使用している場合は、物理的な破損による現象が発生することはほとんどありません。-1018 エラーが頻繁に出力される場合は、ハードウェアの問題 (ほとんどの場合ディスクまたはディスク コントローラの問題) が発生している可能性があります。

ライトバック キャッシュについて : 一部のライトバック キャッシュ アレイ コントローラでは、実際にデータがディスクに保存される前に、正常にコミットされたことを示すメッセージが返されることがあります。プロセスでバッテリ バックアップを使用していない場合は、ライトバック キャッシュを無効にすることをお勧めします。ライトバック キャッシュを使用する場合は、データベースの破損を防ぐために、データが完全に保護されるようにし、クラッシュの発生後に、キャッシュされているデータを適切なディスクに再生できる手段を確保しておきます。

物理的な破損の修復

物理的に破損したデータベースを復旧する唯一の方法は、最新の有効なバックアップ (バックアップの実行時にエラーが発生していない場合、そのバックアップは有効です) からデータベースを復元し、ログ ファイルを再生して、破損する前の整合性の取れた状態に戻すことです。障害が繰り返し発生する場合、データベースを配置しているディスクに問題がある可能性があります。

データベースの物理的な破損を安全に修復する確実な方法はありません。Eseutil.exe ユーティリティを修復モードで実行して、データベースを再度機能させることはできますが、Eseutil ユーティリティでは単純に不良ページが削除されるだけであるため、この方法はお勧めできません。

: Eseutil を修復モードで実行すること (Eseutil /p) は可能な限り避けることをお勧めします。Exchange Server に付属の Eseutil は、他の手段では破損したデータベースを復旧できない場合の最後の手段です。Eseutil を修復モードで実行すると、データベース内の破損したページが削除され、破損したデータベースが再び機能するようになります。データの修復には Eseutil を使用しないでください。Eseutil /p コマンドを実行する場合は、オフラインでの最適化 (Eseutil /d) も実行し、さらに Isinteg -test alltests -fix コマンドを実行して整合性の取れた状態にデータベースを修復する必要があります。

論理的な破損

論理的な破損は、予測不能で、通常ソフトウェアの問題が原因で発生するため、物理的な破損よりも診断や修正が困難です。通常、論理的な破損が発生した場合、ユーザーに警告が通知されます (Exchange Server 5.5 で論理的な破損が発生することは、きわめてまれなケースです)。

論理的な破損の防止

論理的な破損は予測が困難なため、このような破損を防止する確実な方法はありません。ただし、以下の方法を使用して、論理的な破損が発生する危険性を軽減することはできます。
  • 可能な限り早急に Microsoft Exchange Server 5.5 の最新の Service Pack をインストールします。Service Pack をインストールすることにより、Exchange Server 5.5 に関する多くの既知の問題が修正されます。

    Service Pack およびその入手方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
    241740 [XGEN] Exchange Server 5.5 Service Pack 3 で修正された問題の一覧 (Part 2)
    254682 [XADM] Exchange Server 5.5 SP3 以降のデータベース エンジンの修正プログラム
    191014 [XGEN] 最新の Exchange Server 5.5 Service Pack の入手方法
  • Exchange Server コンピュータがセキュリティで保護されていて、構成が変更されていないことを確認します。
上記の対策を実施していても問題が発生し、解決できない場合は、使用中のシステムで新たな問題が発生している可能性があります。このような場合は、早急にマイクロソフトまでご連絡ください。
論理的な破損の修復

論理的な破損は、インフォメーション ストアまたはデータベース エンジンで発生することがあります。論理的な破損が原因でデータに深刻な破損が発生することがあるため、エラーの通知は無視しないでください。

インフォメーション ストアで発生している問題の調査には Isinteg ユーティリティを、また、データベース エンジンで発生している問題の調査には Eseutil ユーティリティを使用できます。これらのユーティリティは、バックアップを使用してシステムを復元できない場合の最後の手段として使用してください。

Isinteg ユーティリティ

インフォメーション ストア整合性チェッカー (Isinteg) ユーティリティを使用して、パブリック インフォメーション ストア データベースおよびプライベート インフォメーション ストア データベースで発生しているエラーを検出および解決できます。これらのデータベースで発生しているエラーが原因で、インフォメーション ストア サービスの開始が妨げられたり、ユーザーのログオンや電子メールの受信、開封、および削除を実行できなくなったりすることがあります。

Isinteg は、インフォメーション ストアの通常の保守作業で使用するためのユーティリティではありません。このユーティリティは、障害発生時の復旧に使用するために提供されているものです。たとえば、システムがクラッシュし、メモリ内にあるインフォメーション ストアのカウントが同期の取れていない状態になった場合、Isinteg を実行してインフォメーション ストアのカウントを修正できます。

Isinteg ユーティリティは論理スキーマ レベルで機能するため、Eseutil ユーティリティで修復できないデータを修復できます。これは、物理スキーマ レベルで Eseutil により有効と判断されたデータが、論理スキーマ レベルでは無効な場合があるためです。ユーザーがデータベースの修復状況を追跡できるように、Isinteg ユーティリティにより、イベント ビューアのアプリケーション ログに情報が出力されます。

Isinteg ユーティリティでは、次の 2 つの主なタスクが実行されます。
  • オフライン バックアップからデータを復元後にインフォメーション ストアを修正します。
  • インフォメーション ストアでエラーが発生するかどうかテストを実行し、必要に応じて、エラーの修正を行います。
インフォメーション ストアおよび Isinteg ユーティリティの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
182081 [XADM] Isinteg ユーティリティの説明

または、Exchange Server 5.5 の CD-ROM の Support\Utils ディレクトリに格納されている Isinteg.rtf ドキュメントを参照してください。

Eseutil ユーティリティ

Eseutil ユーティリティを使用して、データベース テーブルとレコードの構造を検査し、インフォメーション ストアとディレクトリの整合性を最適化、修復、および確認することができます。修復モードの Eseutil では、単純に破損したページが削除されるだけであるため、このユーティリティは、バックアップからデータを復元できない場合にのみ使用するようにしてください。

Eseutil ユーティリティの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
192185 Eseutil ユーティリティ (Eseutil.exe) で最適化を行う方法
または、Exchange Server 5.5 の CD-ROM の Support\Utils ディレクトリに格納されている Eseutil.rtf ドキュメントを参照してください。

データのバックアップ

Exchange Server はトランザクション ベースで実行されるため、ディスク上にあるデータベース ファイルに対してファイル レベルのバックアップまたはオフライン バックアップは実行しないようにします。ディスクにフラッシュされていないトランザクションも含め、システム内のすべてのデータを確実に保持する最も良い方法は、オンライン バックアップを定期的に実行することです。

オンライン バックアップ

オンライン バックアップを実行すると、サーバーをシャットダウンせずに Exchange Server データベースをバックアップ メディアにバックアップできます。Exchange Server でオンライン バックアップを実行しているときも、インフォメーション ストア サービスを含むすべてのサービスは通常どおり実行されます。メモリ内のページは引き続き更新され、ディスク上にあるデータベース ファイルに転送され、トランザクションはログ ファイルに記録され、チェックポイント ファイルも更新されます。

Exchange Server では、バックアップ ソフトウェアの実行中に更新されたページを追跡するための .pat (パッチ) ファイルを使用することで、バックアップ中に変更されたページも確実にバックアップされます。プライベート インフォメーション ストア用の Priv.pat ファイルとパブリック インフォメーション ストア用の Pub.pat ファイルの 2 つの .pat ファイルがあります。

オンライン バックアップを実行する場合は、定期的にイベント ビューアのアプリケーション ログをチェックして、バックアップが正常に実行されていることを確認してください。

オンライン バックアップの処理

Windows NT バックアップ (Ntbackup.exe) などのバックアップ プログラムでは、完全バックアップまたはコピー バックアップで以下の処理が実行されます。
  1. データベースのコピーを作成して、テープにバックアップします。
  2. .pat ファイルにページのサブセットを追加します。これらのページは、テープにコピーされた後に変更が加えられます。
  3. 現在の Edb.log ファイルを Edbx.log という名前に変更し、新しいログの世代を作成します (x は 16 進数形式のログ ファイルの世代番号です)。
  4. 完全バックアップでは、.pat ファイルとチェックポイント以降のすべてのログ ファイルをテープにバックアップします (ただし、新しい Edb.log ファイルはバックアップ対象外です)。コピー バックアップでは、チェックポイント以前および以降のすべてのログ ファイルをバックアップします。
  5. 完全バックアップの場合は、チェックポイント以前のトランザクション ログ ファイルを削除します。コピー バックアップの場合は、トランザクション ログ ファイルは削除しません。
バックアップ プログラムでは、増分バックアップまたは差分バックアップで以下の処理が実行されます。
  1. 増分バックアップの場合は、ログ ファイルのコピーを作成して、テープに保存します。差分バックアップの場合は、データベースをテープにコピーします。
  2. .pat ファイルにページのサブセットを追加します。これらのページは、テープにコピーされた後に変更が加えられます。
  3. 現在の Edb.log ファイルを Edbx.log という名前に変更し、新しいログの世代を作成します。
  4. .pat ファイルとチェックポイント以前および以降のすべてのログ ファイルをテープにバックアップします。新しい Edb.log ファイルもバックアップ対象です。
  5. 増分バックアップの場合は、チェックポイント以前のトランザクション ログ ファイルを削除します。差分バックアップの場合は、ログ ファイルは削除しません。

オフライン バックアップ

オフライン バックアップは、なるべく実行しないようにします。オンライン バックアップでは、バックアップ プログラムによってファイルが管理されますが、オフライン バックアップでは、ファイルを手動で管理する必要があります。これは手間がかかる作業であり、人為的なエラーにつながる可能性があります。また、オフライン バックアップではデータベースの各ページに設定されているチェックサムを検証できません。データの破損を検出し、データの回復を行うのに最も有効なツールは、オンライン バックアップです。

バックアップの関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
191357 [XADM] プライベート / パブリック データベースの一方だけを復元する
179308 [XADM] Exchange オンライン バックアップの検証方法

プロパティ

文書番号: 271987 - 最終更新日: 2006年1月20日 - リビジョン: 5.0
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
キーワード:?
kbinfo KB271987
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

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