次の方法で共有

Exchange 2010 のページの解放について

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

既定では、ほとんどのストレージ システム (ファイル システムとデータベース) は、実際のデータの削除時に、そのデータに上書きしません。データに対するポインターが削除され、データをバックアップしているページとブロックが空き領域または利用可能な領域の一覧に追加されるだけです。ページとブロックが再利用されるときに、データが最終的に削除されます。データの解放とは、データの回復を極めて困難にするために、削除されたデータにゼロまたはバイナリ パターンを上書きするメカニズムです。この処理は、セキュリティ上の理由から行われます。データの解放は、ストレージ システムによってページとブロックが再利用される前に行われます。

Exchange 2010 SP1 でのページの解放

Exchange Server 2010 の Service Pack 1 (SP1) では、ページの解放が既定で有効になっています。これを無効にするメカニズムはありません。ページの解放操作は、トランザクション ログ ファイルに記録されるため、データベースのすべてのコピーで同様にページが解放されます。つまり、アクティブなデータベース上のページを解放すると、ページの解放ログが記録されたトランザクション ログがパッシブなデータベースで再生された後に、パッシブなデータベース上でページが解放されます。Extensible Storage Engine (ESE) には、新しい領域の割り当てに関して解放されたページの再利用の優先順位を付けるメカニズムはありません。シーケンシャルな領域割り当てが割り当てられているテーブルでは、新しいページまたは空きシーケンシャル ページの使用を優先して、断片化または解放されたページを意図的にスキップします。このアプローチは、サーバーのデータベース I/O フットプリントを低減します。

Exchange 2010 SP1 では、データベースのページの解放に対する機能強化によって、解放機能を実行する際のサーバーのパフォーマンスへの影響を低減できます。主な改善点は次のとおりです。

  • ストレージとネットワークの容量の最適化   Extensible Storage Engine (ESE) は、ページ全体のイメージを記録する代わりに、ページ解放レコードをトランザクション ログ ファイルに書き込みます。このアプローチにより、ログ書き込み I/O が減り、ログの容量フットプリントが可能な限り低く抑えられ、ログをアクティブ コピーからパッシブ コピーに移動するための帯域幅要件が低減されます。

  • データベース ディスク I/O の最適化   前のバージョンの Exchange 2010 では、ページの解放は、バックアップまたはスケジュールされた保守プロセス中 (構成されている場合) にのみ実行され、大量のデータベース ディスク I/O が発生しました。Exchange 2010 SP1 では、ページの解放が既定で実行され、主にトランザクション時に行われるようになりました。多くの場合、物理的な削除の直後に解放が行われます。この設計により、データベースはエンジンのチェックポイントの深さを利用できようになり、ダーティ ページが特定の時間キャッシュ内に留まります。このため、短時間の間にページの更新が追加されても、追加のデータベース書き込み I/O が発生しなくなります。こうした設計により、ページの解放によるデータベース I/O への多大な影響がなくなります。既定で、この機能を有効にしている理由はこのためです。

ESE データベースでのページの解放の実装

ESE データベースは、ストレージの単位としてページを使用しており、ページの解放機能を実装しています。ESE のページの解放では、物理的に削除されたレコードごとにバイナリ パターンを一度上書きします。ページの解放パターンは、ESE エンジン操作に固有のもので、実行時操作と保守操作では異なります。次の表に、特定の実行時操作に対応したパターンを一覧表示します。

ESE 実行時操作ごとのページの解放パターン

ESE 実行時操作 パターン

置換

R

レコード/長い値の削除

D

解放されたページ領域

H

次の表は、ESE バックグラウンド データベース保守で実行される特定の操作に対応したパターンの一覧です。

ESE バックグラウンド データベース保守操作ごとのページの解放パターン

ESE バックグラウンド データベース保守操作 パターン

レコードの削除

D

長い値の削除

L

部分的に使用されたページの解放されたページ領域

Z

未使用ページの解放されたページ領域

U

バックグラウンド データベース保守

既定で構成されているバックグラウンド データベース保守は、バックグラウンドで継続的にデータベースのチェックサムとスキャンを実行するプロセスです。この主な機能は、データベース ページのチェックサムを計算することですが、Exchange 2010 ストアがクラッシュした後のクリーンアップ (クラッシュのために実行されなかった領域のクリーンアップおよびレコードとページの解放) も処理します。バックグラウンド データベース保守は、データベースごとに毎秒約 5 MB ずつ処理します。タイムリーなページの解放が優先する場合、データベース サイズを減らして、クラッシュ回復事例に対してより短期間 (たとえば、24 時間) のうちにページを解放するようにできます。詳細については、「新しい Exchange コア ストア機能」を参照してください。

バックグラウンド データベース保守は継続的なプロセスのため、その開始と完了に対して何のイベントも関連付けられていません。次のパフォーマンス カウンターを使用すると、バックグラウンド データベース保守の進捗状況を追跡できます。

  • MSExchange Database =>Instances->Database Maintenance Duration:このパフォーマンス カウンターは、前回指定されたデータベースの保守が完了してから経過した秒数を示します。

ESE データベース ページの解放のプロセス

次の表に、データベースの削除のシナリオ、およびページ解放機能が実行される時点について説明します。

ESE バックグラウンド データベース保守操作

データベースの削除のシナリオ データベース データを解放するための ESE プロセスと期間

  • シナリオ 1: 単一アイテムの回復が無効であり、ユーザーが回復可能なアイテム フォルダーからアイテムを削除します。

  • シナリオ 2: 単一アイテムの回復が無効であり、回復可能なアイテムの保存期間が 0 に設定されています。

  • シナリオ 3: 単一アイテムの回復が有効であり、削除済みアイテムの保存期間に基づいてアイテムの有効期限が決まります。

非同期のスレッドは、バイナリ パターンを削除されたデータに上書きします。この操作はレコード削除の数ミリ秒以内に実行されます。非同期の解放作業がまだ終っていないうちに、ストア プロセスがクラッシュした場合 (またはバージョン ストアが増大したため、バージョン ストアのクリーンアップがキャンセルされた場合) は、バックグラウンド データベース保守 (24 時間 x 7 日) でデータベースの該当するセクションが処理されたときに解放が完了します。バックグラウンド データベース保守の詳細については、「新しい Exchange コア ストア機能」を参照してください。

ビューのシナリオ: Outlook/Outlook Web Access フォルダー ビュー (スレッド ビューなど) のアイテムの有効期限

バックグラウンド データベース保守 (24 時間 x 7 日) でデータベースのこのセクションが処理されたときに、データの解放が行われます。

メールボックスの移動/メールボックスの削除のシナリオ: 移動元メールボックスの削除 (削除済みアイテム収集機能から削除されたメールボックスの有効期限)

バックグラウンド データベース保守 (24 時間 x 7 日) でデータベースのこのセクションが処理されたときに、データの解放が行われます。

ページの解放動作を監視する

ページの解放機能を測定および監視するには、次の ESE パフォーマンス カウンターを使用します。

  • MSExchange Database->Database Maintenance Pages Zeroed:このパフォーマンス カウンターは、パフォーマンス カウンターの起動後に、データベース エンジンによって解放されたページ数を示します。

  • MSExchange Database->Database Maintenance Pages Zeroed/sec:このパフォーマンス カウンターは、データベース エンジンによって解放されたページの速度を示します。

注意

これらのカウンターを有効にする方法については、「拡張された ESE パフォーマンス カウンターを有効にする方法」を参照してください。

ページの解放はデータベース保守機能であるため、ランタイム トランザクション用のページの解放とバックグラウンド データベース保守によるページの解放の両方に関連するパフォーマンス情報がこれらのカウンターに含まれています。

Exchange 2010 メールボックス データとページの解放

メールボックス データベース ファイル (.edb) のみ、ページの解放機能が用意されています。次の Exchange 2010 メールボックス データの種類には、ページの解放機能は用意されていません。

  • メールボックス データベース トランザクション ログ (.log)

    トランザクション ログを削除した場合 (バックアップまたは循環ログによる切り詰めのため)、ログ ファイルをバックアップしている NTFS ファイル システム内のブロックを解放するプロセスはありません。NTFS が新たに作成されるログ用にこの空き領域をすぐ再活用する可能性もありますが、その保証はありません。

  • コンテンツ インデックス カタログ ファイル

    Exchange 2010 は、Exchange Search (MSExchangeSearch) を使用して、検索インデックス処理機能を実行します。検索インデックス カタログは、メールボックス データベース ファイルと同じボリュームに格納されている数十のファイルから構成されています。メッセージがメールボックス データベースから物理的に削除されても、検索カタログ内の関連付けられているコンテンツはすぐには削除されません。コンテンツの削除が行われるのは、MS Search が多数の小さいカタログ ファイルを単一の大きいファイルにシャドウ結合またはマスター結合するときです。マスター結合が完了すると、小さいカタログ ファイルが削除されます。削除されたカタログ ファイルをバックアップしたブロックを解放するプロセスはありません。カタログ ファイルが完全に解放されたことを確認するには、次の手順を使用します。

    1. 影響を受けているサーバー上の MSExchangeSearch プロセスと Microsoft Search (MSSearch) プロセスを停止します。

    2. 影響を受けている各データベース (すべてのコピー上) のカタログ ディレクトリを削除します。

    3. MSExchangeSearch プロセスと MSSearch プロセスを再起動します。

    4. NTFS ブロック解放ツールを使用して、空きブロックを解放します。

    注意

    コンテンツ インデックス カタログ ファイルを削除すると、Exchange 2010 サーバー上のクライアント ユーザー エクスペリエンスに著しい影響が出ます。Outlook Web App および Exchange ActiveSync のサーバーの検索は、各データベースの再クロールによってコンテンツ インデックスでカタログが再構築されるまで停止します。この再構築の完了には、数日から数週間かかる可能性があります。

 © 2010 Microsoft Corporation.All rights reserved.