データベースとログのパフォーマンス要因について

 

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

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

ここでは、Microsoft Exchange Server 2010 における、データベースとログの I/O パフォーマンス要因について説明します。これらの要因を理解することは、メールボックス サーバー記憶域設計ソリューションにとって重要です。設計処理のその他の重要な側面については、「メールボックス サーバーの記憶域設計」を参照してください。

目次

トランザクション I/O

IOPS について

トランザクション以外の I/O

トランザクション I/O

トランザクション I/O は通常、ユーザー操作によって生成された I/O として定義されます。ユーザー操作の例として、アイテムの受信、送信、および削除、Windows モバイル クライアントの同期、および Microsoft Office Outlook Web App 経由のログオンが挙げられます。

トランザクション I/O は、Exchange 2010 の記憶域設計における重要な部分です。なぜなら I/O の遅延 (I/O 処理の実行に要する時間) は、Microsoft Outlook オンライン モードおよび Outlook Web App などの、オンライン クライアントのユーザー エクスペリエンスに直接的に影響するからです。Outlook におけるキャッシュ Exchange モードは、代理人アクセスやルールの構成といったタスクで使用されると、高い I/O 遅延によって影響を受けます。すべてのクライアントは高い I/O 遅延による電子メールの配信遅延の影響を受けます。トランザクション I/O は、データベース ボリューム I/O とログ ボリューム I/O に分けることができます。

Exchange 2010 におけるトランザクション I/O の要件は、Exchange Server 2007 に比べて軽減されています。メールボックス データベースおよびログ ボリュームに対して発生するすべての I/O がトランザクションと見なされるわけではありません。詳細については、「Exchange 2010 のストアについて」を参照してください。

ページのトップへ

IOPS について

各ユーザーによって消費される 1 秒あたりのデータベース I/O の量 (IOPS) は、記憶域の適切な計算方法に必要とされるトランザクション I/O 測定値の 1 つなので、これを理解することは Exchange のすべてのバージョンにおいて非常に重要です。以下のセクションでは、メールボックス サーバーの役割の記憶域を設計する際に、IOPS に影響を与える要因について説明します。

データベース キャッシュ

64 ビット版の Windows Server オペレーティング システムで、64 ビット版の Exchange 2010 を実行する場合は、仮想アドレス スペースが大幅に拡大するので、Exchange のデータベース キャッシュを大きくしてデータベースの読み取り I/O を減らすことができます。また、サーバーあたりのデータベース数は最大 100 個となります。

データベースの読み取り数の減少は、サーバーで利用可能なデータベース キャッシュの容量とユーザーのメッセージ プロファイルによって左右されます。メモリおよびデータベースに関するガイドは、「メールボックス データベース キャッシュについて」を参照してください。そのトピックのガイドに従うと、トランザクション I/O を Exchange Server 2003 より最大 90% 削減できます。ユーザーごとのデータベース キャッシュの容量は、実際の I/O 削減の重要な要素です。

次の表は、1 日に 100 メッセージのプロファイルを使用するユーザー人口に対する、Exchange 2003 のメールボックスあたり既定の 900 MB のデータベース キャッシュと、Exchange 2010 のメールボックスあたり 6 MB のデータベース キャッシュを比較して、実際のデータベース キャッシュの増加量を示しています。この Exchange 2010 における追加のデータベース キャッシュにより、キャッシュでの読み取りヒット数を増やして、ディスク レベルでデータベースの読み取りを削減することができます。

メールボックス数に基づくデータベース キャッシュのサイズ

メールボックス数	メールボックスあたりの Exchange 2003 データベース キャッシュ (MB)	メールボックスあたりの Exchange 2010 データベース キャッシュ (MB)	Exchange 2003 からのデータベース キャッシュの増加
4000	0.225	6	27 倍
2000	0.45	6	13 倍
1000	0.9	6	7 倍
500	1.8	6	5 倍

ページのトップへ

Exchange 2010 メールボックス IOPS プロファイルの決定

Exchange 2010 データベースの IOPS を予測するのに使用できる最も重要な 2 つの要素は、ユーザーごとのデータベース キャッシュの容量と、各ユーザーが 1 日に送受信するメッセージの数です。次の表は、Outlook 2010 を Exchange キャッシュ モードで使用する標準的なワーカーに基づくものです。この情報は、誤差が +/- 20% であることをテスト済みです。クライアントの種類および使用シナリオが異なると、得られる結果が正確でない場合があります。この予測は、サイズが 3 MB ～ 30 MB のデータベース キャッシュに対してのみ有効です。この情報は、ユーザーが 1 日に 500 を超えるメッセージを送受信するようなシナリオでは検証されていません。検証に使用した平均的なメッセージ サイズは 75 KB でしたが、メッセージ サイズは IOPS の主な要因ではありません。

次の表は、ベースライン Exchange 2010 IOPS の要件を予測するのに使用できるユーザーごとの IOPS の予測値を示し、すべてのデータベース I/O (データベース、コンテンツのインデックス処理、および NTFS メタデータ) が含まれています。それには、ログ ボリュームの I/O は含まれていません。

メッセージ アクティビティに基づく、メールボックスあたりのデータベース キャッシュおよび予測される IOPS

1 日にメールボックスあたりで送受信されるメッセージ	メールボックスあたりのデータベース キャッシュ (MB)	1 つのデータベースのコピー (スタンドアロン):メールボックスあたりの予測される IOPS	複数データベースのコピー (メールボックスの復元):メールボックスあたりの予測される IOPS
50	3	0.06	0.05
100	6	0.120	0.100
150	9	0.18	0.150
200	12	0.240	0.200
250	15	0.300	0.250
300	18	0.360	0.300
350	21	0.420	0.350
400	24	0.480	0.400
450	27	0.540	0.450
500	30	0.600	0.500

メールボックスの復元は、Exchange 2010 の統合された高可用性とサイト復元ソリューションを意味します。詳細については、「高可用性とサイトの復元について」を参照してください。

ページのトップへ

データベース ボリュームの I/O

データベース ボリュームの I/O は、NTFS メタデータの読み書きの操作だけでなく、データベース ファイル (.edb) の読み書きの操作、コンテンツ インデックス処理の読み書きの操作と関連付けられた I/O です。

Exchange 2003 では、データベースの読み取りと書き込みの比率は一般に 2 対 1、つまり 66% が読み取りでした。Exchange 2010 では、データベース キャッシュが大きくなったためにディスク上のデータベースの読み取り数が減少し、I/O 全体に対する読み取りの割合は小さくなっています。

推奨されるメモリのガイドラインに従うと、アクティブなデータベース コピーに対して、次の I/O 比率が予測できます。メモリのガイドラインの詳細については、「メモリの構成と Exchange のパフォーマンスについて」を参照してください。この測定には、すべてのデータベース ボリュームの I/O (データベース、コンテンツのインデックス処理および NTFS メタデータ) が含まれ、ログ ボリューム I/O は含まれません。

メールボックス データベース I/O 読み取り/書き込みの比率

1 日にメールボックスあたりで送受信されるメッセージ	スタンドアロン データベース	メールボックスの復元に参加しているデータベース
50	1:1	3:2
100	1:1	3:2
150	1:1	3:2
200	1:1	3:2
250	1:1	3:2
300	2:3	1:1
350	2:3	1:1
400	2:3	1:1
450	2:3	1:1
500	2:3	1:1

例えば、3 つのデータベース コピーを保持するデータベース可用性グループ (DAG) 内のメールボックス サーバーにわたって 24,000 のメールボックスを展開する場合、それぞれのデータベースの読み書き比率は 3.2、言い換えると、データベースをホストしている論理ユニット番号 (LUN) に対するすべての I/O の 60% は読み取り I/O です。

I/O 全体に対する書き込みの割合が増えることは、特に、書き込みに関連するコストが高い種類の RAID (Redundant Array of Independent Disks)、たとえば RAID5 や RAID6 を選択している場合に影響を及ぼします。サーバーに適した RAID ソリューションを選択する方法の詳細については、後の「格納域の構成について」を参照してください。

メールボックス サーバーあたりの IOPS の計算

Exchange 2010 におけるメールボックス サーバーあたりの IOPS の計算には、以下の理由から、以前のバージョンの Exchange よりも多くの手順が必要となります。

• データベースとログを同じボリュームに結合させることができるようになりました。

• 同じサーバー上でアクティブ データベース コピーとパッシブ データベース コピーの両方をホストできます。

• シーケンシャル I/O のバックグラウンド タスク (たとえば、バックグラウンドのデータベース保守) の追加。

記憶域のサブシステムは、シーケンシャル I/O をランダム I/O よりもずっと効率的に処理できるので、シーケンシャル I/O のみの操作は、メールボックス サーバーごとの IOPS の計算に影響しません。これらの操作には、バックグラウンドのデータベースの保守、ログのトランザクション I/O、およびログのレプリケーション I/O が含まれます。

メールボックス サーバーあたりの IOPS は、記憶域の設計によって若干異なります。

• データベース ファイルとログ ファイルが、1 つのボリュームを共有している。

• データベース ファイルがトランザクション ログ ファイルとは別のディスク ボリュームに保存されている。

どちらの記憶域設計でも、パフォーマンス モニター (perfmon.exe) を使用して、ピーク時の 2 時間を計測します (5 秒間のサンプリング間隔)。これは 1 日のうちで、クライアントの操作によって最も重い負荷がシステムが生成される時間帯です (たとえば、午前 10 時から午後 12 時)。この期間はしばしば 10 時間の毎日の平均の 2 倍になります (ピーク: 平均の比率 = 2:1)。

メールボックス サーバーあたりの IOPS:データベース ファイルとログ ファイルが、1 つのボリュームを共有する

この構成では、データベース ファイルとログ ファイルは同じディスク ボリュームに保存されます。この例では、各データベースが専用のディスクからなる異なるボリュームにあることを前提としています。収集したパフォーマンス ログから、すべてのデータベースについて以下の表に記入します (以前のセクションで説明)。

データベース名	Logical Disk -> Disk Reads/sec	Logical Disk -> Disk Writes/sec	MSExchange DatabaseInstances ->Database Maintenance IO Reads/sec	MSExchange DatabaseInstances ->I/O Database Reads (Recovery)/sec	MSExchange DatabaseInstances ->I/O Database Writes (Recovery)/sec	MSExchange DatabaseInstances ->IO Log Writes/sec
データベース 1
データベース 2
データベース 3
データベース 4
その他のデータベース
合計

合計をそれぞれの列から追加して、以下の計算を実行し、メールボックス サーバーあたりの IOPS を決定します。

計算の概要:Logical Disk IO の合計 - (データベース保守 IO の合計 + 回復 (ログの再生) IO + ログ IO) を、パフォーマンス モニターのログ測定の間の、サーバーごとにホストされたメールボックスの数で割ったもの。

計算の詳細:((Logical Disk -> Disk Reads/sec + Logical Disk -> Disk Writes/sec) - (MSExchange Database ==> Instances -> Database Maintenance IO Reads/sec + MSExchange Database ==> Instances -> I/O Database Reads (Recovery)/sec + MSExchange Database ==> Instances -> I/O Database writes (Recovery)/sec + MSExchange Database ==> Instances -> IO Log Writes/sec))/ パフォーマンス モニターのログ測定の間の、サーバーごとにホストされたメールボックスの数 = メールボックス サーバーあたりの IOPS。

ページのトップへ

IOPS/メールボックス:専用のデータベース ファイルのボリューム

この構成では、データベース ファイルとトランザクション ログ ファイルとは別のディスク ボリュームに保存されています。この例では、各データベースが専用のディスクからなる異なるボリュームにあることを前提としています。収集したパフォーマンス ログから、すべてのデータベースについて以下の表に記入します (以前のセクションで説明)。

データベース名	Logical Disk -> Disk Reads/sec	Logical Disk -> Disk Writes/sec	MSExchange Database ==> Instances ->Database Maintenance IO Reads/sec	MSExchange Database ==> Instances ->I/O Database Reads (Recovery)/sec	MSExchange Database ==> Instances ->I/O Database Writes (Recovery)/sec
データベース 1
データベース 2
データベース 3
データベース 4
その他のデータベース
合計

注意

既定では、Exchange 2010 で MSExchange Database ==> Instances ->Database Maintenance IO Reads/sec パフォーマンス カウンターは表示されません。このカウンターを表示するには、有効にする必要があります。このパフォーマンス カウンターを有効にする方法の詳細については、「拡張された ESE パフォーマンス カウンターを有効にする方法 (英語の場合があります)」を参照してください

メールボックス サーバーあたりの IOPS を特定するには、各列の合計を加算し、次の計算を実行します。

計算の概要:Logical Disk IO の合計 - (データベース保守 IO の合計 + 回復 (ログの再生) IO) を、パフォーマンス モニターのログ測定の間の、サーバーごとにホストされたメールボックスの数で割ったもの。

計算の詳細:((Logical Disk -> Disk Reads/sec + Logical Disk ->Disk Writes/sec) - (MSExchange Database ==> Instances -> Database Maintenance IO Reads/sec + MSExchange Database ==> Instances -> I/O Database Reads (Recovery)/sec + MSExchange Database ==> Instances -> I/O Database writes (Recovery)/sec))/ パフォーマンス モニターのログ測定の間の、サーバーごとにホストされたメールボックスの数 = メールボックス サーバーあたりの IOPS。

ベースライン IOPS の測定

旧バージョンの Exchange を使用していて、ベースライン IOPS を計算したことがある場合は、Exchange 2010 は次の点でベースラインに影響することに注意してください。

• サーバー上のユーザー数は、ユーザーごとのデータベース キャッシュ全体に影響します。

• RAM の容量はデータベース キャッシュが取り得る最大サイズに影響します。データベース キャッシュが大きいと、キャッシュの読み取りヒット率が向上します。これにより、データベースの読み取り I/O が低減されます。

この処理の重要な点は、特定サーバー上の IOPS だけでは、エンタープライズ全体を計画するのに十分な情報とは言えません。RAM 容量、ユーザー数、データベース数は、各サーバーにより異なるためです。実際の IOPS の数値が得られたら、計算時は必ず 20% のオーバーヘッド係数を掛けて、余裕を持たせるようにします。アクティビティの負荷が通常より高いときも、ユーザーの操作性が低下してはならないからです。

デスクトップ検索エンジンと Outlook オンライン モード クライアント

Exchange キャッシュ モードのクライアントとは異なり、オンライン モードのクライアントの操作はすべてデータベースに対して行われます。ストア スキーマと ESE (Extensible Storage Engine) の変更のため、Outlook オンライン モード クライアントは、OutlookExchange キャッシュ モード クライアントと同じ I/O プロファイルを生成するようになりました。

メールボックスの検索機能に関して、エンド ユーザーには 2 つのオプションがあります。

• エンド ユーザーは、メールボックス サーバーで利用できる組み込みのコンテンツ インデックスを使用できます。

• エンド ユーザーは、デスクトップ検索エンジン クライアントをインストールして、クライアント上にメールボックスのデータのローカル インデックスを生成し、ローカル検索を実行します。

Outlook オンライン モードでデスクトップ検索エンジン クライアントを使用するエンド ユーザーによって、データベースに対して追加の読み込み I/O 操作が発生する可能性があります。現時点で、追加の読み込み I/O が発生しないことで知られているデスクトップ検索エンジンは Windows デスクトップ サーチ 4.0 だけです。Windows デスクトップ サーチ 4.0 は、OutlookExchange キャッシュ モードの同期プロトコルがメールボックスのコンテンツをインデックス処理する方法と似たような、同期プロトコルを使用します。

このため、Outlook オンライン モード クライアントを Windows デスクトップ サーチ 4.0 より古いデスクトップ サーチ エンジンで展開する場合は、以下のガイドラインを使用します。

• 256 MB オンライン モードのクライアントは、Exchange キャッシュ モードのクライアントと比較して、データベースの読み取り操作数が 1.5 倍になります。256 MB 未満の場合、影響はごくわずかです。

• メールボックスのサイズが倍になると、データベースの読み取り IOPS も倍になります (主要フォルダー間での均等なアイテム分布が変わらないと仮定した場合)。

このデータの結果、2 つの推奨事項があります。

• 可能であれば、Exchange キャッシュ モードのクライアントを展開します。詳細については、このトピックの後半の「フォルダーごとのアイテム数」を参照してください。それ以外の場合は、デスクトップ検索エンジンを Windows デスクトップ サーチ 4.0 に置き換えます。

• データベース ストレージをデザインする場合は、I/O の要件を検討します。

IOPS に関係するこの他の要因 (サード パーティ クライアントなど) については、「Exchange Server 2003 の記憶域の最適化 (英語の場合があります)」を参照してください。

ページのトップへ

ログ ボリュームの I/O

ログ ボリュームの I/O は、データベース ログの読み込み/書き込み操作および NTFS メタデータの読み取り/書き込み操作に関連付けられた I/O です。ログ ボリューム I/O は本質的にシーケンシャルで、バッテリー バックアップの書き込みキャッシュ アレイ コントローラーを使用する場合、ログ ボリューム I/O の I/O オーバーヘッドは最小限で、Exchange ストレージのサイズ決定に関して重要な要因ではありません。

Exchange 2010 でのデータベースの読み取りが減少したことと、ログ ファイルのサイズが小さくなって、作成できるデータベース数が増えたことにより、ログとデータベースの書き込み比率は、スタンドアロン データベースで 40%、メールボックスの復元に参加しているデータベースで 50% になります。たとえば、メールボックスの復元に参加しているデータベースが 12 の書き込み I/O を使用する場合、ログ LUN は約 6 の書き込み I/O を使用します。

メールボックスの復元に参加しているデータベースをホストしているメールボックス サーバー上で、連続レプリケーションの使用に関連するオーバーヘッドがあります。閉じられたトランザクション ログは読み込まれ、ターゲット データベースのコピーに送信される必要があります。このオーバーヘッドは、メールボックス サーバー上でホストされているアクティブなデータベース コピーそれぞれのログ読み込みで 10% 追加されます。たとえば、メールボックス サーバーが 10 のアクティブ データベース コピーをホストしていて、各トランザクション ログ ストリームが 6 つの書き込み I/O を生成している場合、それら 10 のアクティブ データベース コピーのそれぞれについて追加で 0.6 の読み込み I/O が予想できます (または合計で 6 の読み込み I/O)。

測定または予測によってトランザクション ログ I/O の数を求めたら、20% の I/O オーバーヘッド係数を掛けて、通常より I/O の多い期間にも十分に対応するための余地を確保してください。

フォルダーごとのアイテム数

サーバー I/O を減らす 1 つの方法は、Outlook を Exchange キャッシュ モードで使用することです。初期のメールボックスの同期処理はディスクを集中的に使用する操作ですが、時間が経過してメールボックス サイズが大きくなるにつれて、ディスク サブシステムの負荷が Exchange サーバーから Outlook クライアントに移っています。Exchange キャッシュ モードを使用することで、ユーザーが受信トレイに非常に多くのアイテムを残していたり、メールボックスの検索を実行したりしても、サーバーにはほとんど影響しないことを示しています。この方法はまた、大きなメールボックスを持つ Exchange キャッシュ モードのユーザーは、小さなメールボックスを持つユーザーより高速のコンピューターを必要とする場合があることを示しています (許容可能なパフォーマンスに対する個々のユーザーのしきい値によって異なります)。

Exchange キャッシュ モードで Outlook 2007 を実行するクライアント コンピューターを展開するときは、メールボックスの /.ost ファイルのサイズに関して以下のガイドラインを考慮してください。

• 最大 5 GB   このサイズでは、ユーザーはほとんどのハードウェアを快適に使用できます。

• 5 GB ～ 10 GB   このサイズでの操作性は、通常、ハードウェアに依存します。したがって、高速なハード ディスクと多くの RAM を使用している場合は操作性が向上します。ただし、ラップトップや古い世代のソリッド ステート ドライブ (SSD) で通常見られるドライブなどの低速なハード ドライブを使用している場合は、ドライブの応答時にアプリケーションが一時停止することがあります。

• 10 GB を超えるサイズ   このサイズでは、ほとんどのハードウェアで短時間の一時停止が発生し始めます。

• 25 GB 以上の非常に大きなサイズ   このサイズでは、特に新しい電子メールのダウンロード中などに、短時間の一時停止が頻繁に発生します。代替手段として、送受信グループを使用してメールを手動で同期できます。

このガイダンスは、「2009 年 2 月 24 日リリースの Outlook 2007 修正プログラム パッケージ (Outlook.msp) (英語の場合があります)」についての Microsoft サポート技術情報の記事 961752 に記載されている、Outlook 2007 Service Pack 1 以降の累積的な更新プログラムのインストールに関する情報に基づいています。

Outlook 2007 キャッシュ モードでの Exchange の展開でパフォーマンスに関する問題が発生している場合は、「Outlook 2007 でのパフォーマンスの問題のトラブルシューティング方法 (英語の場合があります)」についての Microsoft サポート技術情報の記事 940226 を参照してください。使用可能な、強化された機能の詳細については、「2009 年 2 月の累積的な更新プログラムにおける Outlook 2007 の機能強化 (英語の場合があります)」についての Microsoft サポート技術情報の記事 968009 を参照してください。

問題となるシナリオの 1 つは、ユーザーが Exchange で保存されるインデックス数を超えてしまった場合に起こります。Exchange 2010 の場合は 11 インデックスです。ユーザーが新しい方法で並べ替えるよう選択すると、12 番目のインデックスが作成され、新たなディスク I/O アクティビティが発生します。インデックスは保存されないため、この並べ替えが実行されるたびに、この新たなディスク アクティビティ コストが発生します。このシナリオでは大量の I/O アクティビティが発生する可能性があるので、受信トレイ フォルダーや送信済みアイテム フォルダーなどのコア フォルダーに格納するアイテム数は 100,000 以内に、予定表フォルダーや連絡先フォルダーに格納するアイテム数は 10,000 以内にすることを強くお勧めします。通常、トップレベル フォルダーをさらに作成するか、または受信トレイ フォルダーや送信済みアイテム フォルダーのサブフォルダーを作成することで、このインデックスの作成に関連するコストを大幅に削減することができます。どのフォルダーのアイテム数も 100,000 未満である限り、コストを削減できます。

ページのトップへ

コンテンツ インデックスの I/O

Exchange 2010 では、メッセージは受信されるとインデックス処理され、わずかなデータベース ディスク I/O のオーバーヘッドが発生します (なぜなら、メッセージがインデックス処理のために受信される時、メッセージは依然としてデータベース キャッシュにあるからです)。ただし、書き込み I/O は、検索カタログ ストアの更新に関連付けられています。Exchange 2010 におけるデータベース I/O 全体の削減により、検索カタログ I/O の比率は今ではデータベース ファイル I/O の 10 ～ 15 %です (プロファイルに依存)。検索カタログの読み込み I/O はクライアントが検索クエリを発行する時に発生し、Exchange 2010 ストレージ設計と関連するほど頻繁には発生しません。

ページのトップへ

トランザクション以外の I/O

トランザクション I/O は直接的なユーザー操作に応答して発生します。通常は最も高い優先度が与えられ、そのため記憶域の設計の中心となります。トランザクション以外の I/O はバックグランドで発生してパフォーマンスに最小限の影響を与えるように調整するか、または定義した保守ウィンドウ期間中に発生するようにするかのいずれかです。

以下のセクションでは、バックグラウンドで発生する、トランザクション以外の I/O のいくつかについて説明します。トランザクション以外の I/O はストレージ設計の対象ではありませんが、ストレージ設計に対して影響を与えることがあります。詳細については、「新しい Exchange コア ストア機能」を参照してください。

バックグラウンド データベース メンテナンス (チェックサム)

バックグラウンド データベース メンテナンス I/O は、アクティブおよびパッシブ データベース コピーのチェックサム計算に関連付けられた、シーケンシャル データベース ファイル I/O です。バックグラウンド データベース メンテナンスには、次の特徴があります。

• アクティブ データベースでは、年中無休 (24 x 7) またはオンライン メンテナンス ウィンドウの間のいずれかに実行するよう構成できます。バックグラウンド データベース メンテナンス (チェックサム) はパッシブ データベース コピーに対して年中無休 (24 x 7) で実行されます。詳細は、「新しい Exchange コア ストア機能」トピックの「オンライン データベース スキャン」を参照してください。

• アクティブにスキャンしている各データベースに対して、毎秒約 5 MB の速度で読み込みを行います (アクティブおよびパッシブ コピーの両方)。その I/O は 100% シーケンシャルなので、ストレージ サブシステムは効率的に I/O を処理できます。

• チェックサム パスが 24 時間以内に完了する場合は、データベースのスキャンを停止します。

• スキャンが 3 日以内 (変更不可) に完了しない場合は、警告イベントが発行されます。

メッセージング レコード管理

メッセージング レコード管理 (MRM) は Exchange 2010 のレコード管理テクノロジで、組織での電子メールに関連する法的リスクの軽減に役立ちます。MRM を使用すると、企業ポリシー、政府規制、または法的要件への準拠に必要なメッセージを保持し、法的価値またはビジネス上の価値を持たなくなったコンテンツを削除することがより簡単になります。

これらの操作は、アイテム保持ポリシーまたは管理フォルダーによって実現できます。管理フォルダー アシスタントは、アイテム保持ポリシーまたは管理フォルダー用メールボックス ポリシーに構成されたメッセージ保持設定を適用する Microsoft Exchange メールボックス アシスタントです。アシスタントによって要求されるディスク I/O は、処理するメールボックス アイテムの数に依存します。バックアップまたはオンライン保守と同時にアシスタントを実行しないことをお勧めします。詳細については、「管理フォルダー アシスタントをスケジュールする」を参照してください。

オンライン保守

Exchange 管理ツールを使用すると、データベースのメンテナンス スケジュールを設定したり、年中無休 (24 x 7) のデータベース メンテナンスを設定できます。オンラインでの最適化は、Exchange 2010 では以前のバージョンの Exchange のようには機能しなくなりました。オンラインでの最適化は、データベースの読み込み時と書き込み時には引き続き実行されます。詳細については、「新しい Exchange コア ストア機能」の「オンライン データベース スキャン」を参照してください。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.