Partager via

Exchange 2010/2013 のデータベース サイズの増大に関するレポート作成のスクリプト

  • Article

Exchange 2010/2013 のデータベース サイズの増大に関するレポート作成のスクリプト

はじめに

Exchange サポートのもとに、Exchange データベースのサイズが異常に増大するという報告がたびたび届いています。「データベースのサイズが増えているが空きスペースを確保できない」というものや、「あるサーバー上の全データベースのサイズが急激に増えているが、トランザクション ログの生成速度は正常である」というものなど、質問や相談の内容はさまざまです。ここでは、データベースで実際に何が起きているかを把握し、必要なデータを収集できるようにするために私たちが作成したスクリプトをご紹介します。ログのサイズが増大する問題については、Kevin Carker が執筆したこちらのブログ記事 (英語) を参照してください。

マイクロソフト サポートとの共同作業の際には、追加でデータの取得が必要となる場合があります。たとえば、このスクリプトでは、メールボックス データベースのパフォーマンス監視ログなどのデータは取得されません。マイクロソフトでは、皆様からお寄せいただいたフィードバックに基づいて、今後開発する追加機能を決定しています。皆様にはこのスクリプトをテストしたうえでご活用いただきたいと考えていますが、 マイクロソフトが公式にサポートしているものではない という点についてはご了承ください。また、ここでご紹介するほとんどのスクリプトでは、Exchange のデータを変更することは一切ありません。データの抽出と比較を行うだけです。

注意: 領域ダンプ機能を使用すると、対象ノードでは Microsoft Exchange のレプリケーション サービスが停止 (および再開) され、選択されたデータベースのパッシブ コピーにトランザクション ログが再配信されるため、使用時には注意が必要です。データベースの空き領域を正確に取得する方法は領域ダンプ以外にないため、この機能を導入しました。AvailableNewMailboxSpace が空き領域と同等であると考えている方も多いかと思いますが、Ross Smith IV が執筆した Exchange 2010 のデータベース保守に関するブログ記事 (英語) では、次のように説明されています。「Exchange 2010 のデータベースではステータス プロパティが使用できますが、これはデータベースの空き領域の合計を表すものではありません。AvailableNewMailboxSpace はデータベースのルート ツリーで使用可能な領域の量を示していて、メールボックス テーブルやインデックス テーブルなどの空きページが含まれていません。このため、データベースの空き領域とは異なります」。データベースのコピーの遅延によりクリーン シャットダウン状態になることを避ける場合などは、繰り返しになりますが、スクリプトの機能を使用する際に注意が必要です。

データベース サイズの増大に関するトラブルシューティングでは、削除されたアイテムの合計サイズと訴訟ホールド中のユーザーの有無を必ず確認する必要があります。それではスクリプトの説明に入りましょう。

次に示すコマンドの組み合わせを使用すると、特定のデータベースに存在する訴訟ホールド中の任意のユーザーについて、メールボックスの統計がエクスポートされます。さらに、該当するユーザーの回復可能なアイテム フォルダーに存在するアイテムの合計が出力されます (訴訟ホールドが有効になっている場合、Versions および Purges の各サブフォルダーが使用されることに注意してください)。

1. 訴訟ホールドが有効になっているデータベースごとに、ユーザーのメールボックスの統計をエクスポートします。

get-mailbox -database <database name> -Filter {LitigationHoldEnabled -eq $true} | get-mailboxstatistics | Export-CSV LitHoldUsers.csv

2. 変数として新しい CSV ファイルをインポートします。

$stats = Import-Csv .\LitHoldUsers.csv

3. 訴訟ホールド中のユーザーについて、削除済みアイテムの合計サイズをスプレッドシートに取得します。

$stats | foreach { $bytesStart = $_.TotalDeletedItemSize.IndexOf("(") ; $bytes = $_.TotalDeletedItemSize.Substring($bytesStart + 1) ; $bytesEnd = $bytes.IndexOf(" ") ; $bytes = $bytes.Substring(0, $bytesEnd) ; $bytes } | Measure-Object –Sum

以上の操作で、特定のデータベースに存在する、訴訟ホールド中のユーザーが所有する回復可能なアイテムの合計がわかります。実際の事例の中には、この量がデータベース全体の 75% 以上となっている場合もありました。この他に、使用中の Exchange のバージョンを確認することもできます。既知の保存内容が漏えいする不具合がありましたが、これについては Exchange 2010 SP3 RU1 に含まれている修正プログラムで対処できます。ナレッジベースではまだこの修正情報が更新されていないようですが、修正自体は完了しています。スクリプトの検証を進める前に、SP3 RU1 をインストールして問題が修正されていることを確認してください。

それでは、スクリプトの説明に戻ります。このスクリプトでは、次のことが可能です。

  • 指定したデータベース全体でメールボックスの統計を収集し、将来的に差別化で使用するための変更可能な記録プロパティを追加する。
  • 指定したデータベースのデータベース統計を収集し、将来的に差別化で使用するための変更可能な記録プロパティを追加する。
  • 指定したデータベースのすべてのメールボックスでメールボックス フォルダーの統計を収集し、将来的に差別化で使用するための変更可能な記録プロパティを追加する。
  • 差分データベースと入力データベースのサイズとアイテム数の属性を比較し、更新された属性と共にデータベースの種類のオブジェクトを返す。
  • 差分メールボックスと入力メールボックスのサイズとアイテム数の属性を比較し、更新された属性と共にメールボックスの種類のオブジェクトを返す。
  • 差分フォルダーと入力フォルダーのサイズとアイテム数の属性を比較し、更新された属性と共にフォルダーの種類のオブジェクトを返す。
  • 差分レポートと入力レポートのサイズとアイテム数の属性を比較し、更新された属性と共にレポートの種類のオブジェクトを返す。
  • レポート (データベース、メールボックス、フォルダーの統計) を、指定したパスまたは現在の ディレクトリに XML 形式でエクスポートする。
  • XML 形式のレポートをインポートし、CSV 形式でエクスポートする。
  • 特定のパスのファイルからレポートの詳細をインポートする (データベース、メールボックス、フォルダーの統計)。
  • データベースの詳細、およびサイズが大きいメールボックスとフォルダーの上位 25 個をそれぞれ出力する。
  • 領域ダンプ、および ESEUTIL /MS を、指定したデータベースのパッシブ コピーから収集し、テキスト (TXT) 形式で書き出す。
  • オンライン メンテナンスの重複および破損の可能性に関するイベントを検索し、画面に出力する。
  • 現在の格納領域使用率の統計を収集し、CSV 形式でエクスポートする。

スクリプトはこちらのページ (英語) からダウンロードできます。

サンプル スクリプトの実行

報告された問題: “Mailbox Database 0102658021” のサイズが急速に増大しています。

  • -mode switch と併用可能なオプションのリストを表示します。

  • サイズが増大しているデータベースを選択し、データを収集およびエクスポートします (mode 1 と入力)。
  • パスを指定するか、または現在の作業ディレクトリを使用するように選択します。パス前後の引用符はオプションですが、パスは必ず存在するものである必要があります。
  • データベース名を指定します。このデータベースではアクティブ コピーが実行されます。引用符はオプションです。

  • この処理は、データベースのサイズやフォルダー数などに応じてある程度の時間が掛かります。レポートの生成が完了したら、各レポートで上位何個のアイテムを表示するかを選択します。既定では 25 個に設定されています。Enter キーを押して決定します。

  • 画面出力用のレポートが生成されます。ディスク上のデータベース サイズは 1.38GB でした。

画面上のレポートをスクロールすると、データベースのサイズの詳細が表示されます。また、サイズ、DeletedItemSize の値、アイテム数、削除済みアイテム数、関連アイテム数のそれぞれで上位 25 個のメールボックス、およびサイズ、アイテム数、削除済みアイテム数のそれぞれで上位 25 個のフォルダーも表示されます。

XML 形式の完全なレポートは、ユーザーが指定した場所に保存されます。

PowerShell のウィンドウを閉じた後に再度レポートを表示する場合は、スクリプトを mode 2 で実行します (引用符はオプション)。

これで、特定の時間におけるデータベースの状態の有効なレポートが得られます。今回は「データベース サイズの増大」という問題に対するトラブルシューティングなので、サイズが増大するまでしばらく時間を置きます。データベース ドライブに十分な空き領域がある場合、24 時間ごとにレポートを実行します。

準備ができたら、データベースの 2 回目のレポートを収集します (手順は 1 回目と同じです)。

Enter キーを押して、上位 25 個のアイテムを画面に表示します。下の例では、ディスク上のデータベース サイズが 1.38 GB から 1.63 GB に増大しているのがわかります。

次に、スクリプトの Mode 3 を使用して 2 つの XML レポートを比較し、何のサイズが増えたかを確認します。ディレクトリに存在する 2 つ目の XML レポートがどれであるかを確認します。

スクリプトを –mode 3 で実行します。このとき、元のレポート、およびデータベース サイズの増大が確認された後に生成された 2 つ目のレポートについて、それぞれ完全なファイル パスを入力する必要があります。

比較が完了したら、最初の 2 つのレポートと同様の形でレポートが出力されます。ただし、これは、特定のフォルダーでのアイテムの増加数やデータベース サイズの増大分などを示す 差分 のレポートですので、ご注意ください。

上の例では、ディスク上のサイズが 256 MB になっていることがわかります。データベースのサイズは 1.38 GB から 1.63 GB に増大したため、その差が出力されています。スクロールしてレポートの続きを確認すると、Administrator メールボックス (筆者がコンテンツを追加した場所です) が増大分のほとんどを占めていることがわかります。

このデータから、さらなるサイズ増大の原因を追究できる場合があります。先に述べたように、既知の保存内容が漏えいする不具合により、「不可解な」サイズ増大が発生する場合がありました。Exchange 2010 SP3 RU1 をインストールするとこの問題は解消されますので、必ずインストールしてください。このような事態が発生した場合でも、出力されたデータを見ると、データベースのディスク上のサイズが増大していながらメールボックスのサイズが実際には増大していないことがわかります。この場合には、マイクロソフトのサポートへご連絡ください。

ここで、実際のオーバーヘッド値について簡単にご説明します。この値は、データベースの物理サイズから AvailableNewMailboxSpace、TotalItemSize、および TotalDeletedItemSize の値を引いて算出します。既に述べたとおり、AvailableNewMailboxSpace は実際の空き領域のサイズではありません。実際の値は、このレポート結果よりも若干大きくなります。

スクリプトの他のパラメーター

スクリプトの実行時に選択可能な他のモードについては、以下の説明をご覧ください。

Mode 4 – 格納領域使用率の統計をエクスポートします。組み込みの Get-StoreUsageStatistics 関数を使用して、サーバーまたはデータベース レベルで実行されます。

Mode 5 – オンライン メンテナンスの重複および破損の可能性に関するイベントのアプリケーション ログを検索し、画面に出力します。ここではすべてのイベントのリストを取得しているとは限らないため、未処理のイベントがあれば追加できます。

Mode 6 – データベースのパッシブ コピーを実行するサーバーを検索します。遅延コピーとして構成されたものについては、ユーザーに警告します。正確な空き領域を確認するためにパッシブ コピーに対してこれを実行する場合は、Microsoft Exchange のレプリケーション サービスが停止され、パッシブ コピーをクリーン シャットダウン状態にするために必要なログのソフトの再配信が行われ、続いてパッシブ コピーに対して ESEUtil /MS が実行されます。完了後、レプリケーション サービスが再開されます。

Mode 7 – Mode 1 で作成された XML レポートのいずれかを読み取り、CSV 形式で個々のコンポーネントのレポートに分割します。

データベース サイズが増大する事例が絶えないため、Newgard と私は共同でこのスクリプトを構築しました。アイデアを提供し、中核コンポーネントのコンパイルを担当してくれた彼に感謝します。トラブルシューティングに関連して、私たちはそれぞれ別々のスクリプトを構築したのですが、残念ながら彼のコア スクリプトの方が優秀でした (私も補助コンポーネントをいくつか追加しました)。また、デバッグ作業の観点からこれらの事例に多数かかわり、このアイデアの素を提供してくれた Bill Long、そしてテクニカル レビューを担当してくれた David Dockter と Rob Whaley にも感謝します。

この記事が皆様のデータベース サイズ増大のトラブルシューティングにお役に立てれば幸いです。この件に関する皆様からのコメント、および改善のご提案がありましたらぜひお寄せください。お待ちしております。

最後までお読みいただき、ありがとうございました!

Jesse Newgard、Charles Lewis
シニア サポート エスカレーション エンジニア