none
【緊急】Exchange Server 2003のデータベース(priv1.edb、priv1.stm)容量削減方法を教えてください!!!! RRS feed

  • 質問

  •  

    Exchange Serverのデータベース(priv1.edb、priv1.stm「長時間で溜まったメールデータ」)が、肥大化しディスク容量を圧迫しています。また、今Exchange Server上でのメールデータが全部不要のため、削除してもかまいません。

    <すでに知っている方法>

     方法①クライアント端末からメーラー(Outlook・・・)でExchange Serverからメールを受信して、またExchange  

           server上でデフラグ処理を実行します。

      方法②Exchange Server上でメーラー(Outlook・・・)でメールを受信して、またデフラグ処理を実行

    <質問>

      メール受信以外に何か方法がありますか?(例、簡単のバッチ実行などの裏技とか。。。)

    以上 よろしくお願いします!!!!!!

    2012年3月1日 9:20

回答

  • もう少し何がどうなのかを 正確に確認した方が良いかもしれないですね。

    そもそも論。

      Exchange Server にとっての空き容量について。

       priv1.edb / priv1.stm  のデータベースファイルの合計サイズが 10GBだった場合。

       このデータベース内にメールボックスを作成されている10名のユーザー user1 ~ user10 の保持データ量が現時点で9GB だった場合、 

       Exchange Server 的には、データベース内に 1GB の空き容量が空いている、と認識しています。

       この空き容量を増やしたい場合、

        1. 各ユーザーの不要なメールを削除する。(削除済みアイテムフォルダも空にする)

        2. データベースのプロパティの削除済みアイテム保存期間を 0日 にする。 

        3. クリーンアップを実行する。

       という手順で、もし各ユーザーが 100MB ずつ 不要メールを削除してくれていたら、 データベース内に 1000MBの空き容量が増えます。

       priv1.edb / priv1.stm  の物理ファイルサイズは変更されません。 10GBのままですが、内部の未使用領域が広がり、約2GBの空き容量を確保できます。

     メールボックス単位の使用量制限について

       データベースなにがしと関係なく、  user1 に対してメールを送信する 容量不足で弾かれるとか、 user1 がメールを送信しようとすると容量不足で弾かれる というのは

       メールボックスデータベースのプロパティまたは受信者のアカウントのプロパティのどちらかで、 送信を禁止するサイズ、 送受信を禁止するサイズが設定してあり、

       user1 の保持するサイズがその制限値を上回っている可能性があります。

       その場合は、 user1 に不要なメールを削除させる、 か ディスクの空き容量に余裕があるなら、制限値を緩和する。

     物理ディスク領域の不足

       サーバーのデータ領域のハードディスク容量が  100GB で、 データベース容量が 40GBぐらいの場合。

       → 前述の3手順を実施して、そもそもデータベース内部の空き容量(物理的に圧縮されても構わなくなる領域)を広げます。

       1. データベースの完全バックアップを取得します(Exchange Serverデータベースのバックアップに対応しているバックアップソフトでバックアップを実行します)

         バックアップを取得したことにより、データベース内の空き領域が物理サイズとして縮小されていい形にマークされます。

         ※ もしかしたら、クリーンアップを実行する前にバックアップを取った方がより良かったかもしれません。

       2. オフラインデフラグを実施します。

         オフラインデフラグは、元のデータベースサイズx1.2倍の空き容量が必要になる事があります。 40GBのデータベースに対して処理すると 48GBの空き容量が

         ないと失敗する可能性があります。

         この例では、60GB 空き容量があるので実施できることになります。 もし、データベースサイズが 50GB を超えていたら、空き容量が元のデータベースサイズを下回るので

         オフラインデフラグは失敗する可能性が高くなります。

         オフラインデフラグに成功すると、最終的なデータベースの物理サイズが小さくなります。

         物理サイズ 40GB 中 空き容量が 10GB 確保できていたとしたら、 最終サイズは 30GB くらいになる可能性があります。

    メーラーで受信する、の意味するところが Exchange Server 側メールボックスないのデータを全部クライアント側に移す、という事であれば、

    その後にクリーンアップ手順が必要になると思います。

    仮にその Exchange環境が本番環境でなくテスト環境で有り、メールデータその物どうでもいいのであれば、すべてのユーザーのメールボックスを削除して

    すべてのユーザーの Exchange属性もクリアして、 そもそもデータベースを削除して、データベースそのものを作り直す、というのも

    アリかな、とは思います。

    • 回答としてマーク 星 睦美 2012年3月9日 4:37
    2012年3月2日 5:22
  • クライアントからメールを削除しても、削除済みアイテムの保存期間の間は残ってます。

    データベースの保守で、オンラインデフラグをやっても「空き領域」としてマークされたところができるだけで、.edb のファイルサイズは小さくなりません。

    オフラインデフラグをやる場合は、データベースファイルサイズの 1.2 倍以上の空き領域が必要です。

    したがって、大きいディスクを買ってきてそこにデータベースを丸ごと移動しましょう。これが緊急の対応方法として一番現実的です。

    # 一度サービスを止めて、priv1.stm を消す。というのも無きにしもあらずだが。。。

    • 回答としてマーク 星 睦美 2012年3月9日 4:37
    2012年3月2日 8:51

すべての返信

  • 緊急であれば、マイクロソフトの有償サポートに問い合わせ・・・という議論を置いておきますが、

    オンラインおよびオフラインデフラグ以外には、DBが格納されてる領域をリサイズして拡大する方法ぐらいしかないと思います。

    (おそらく、それも出来ないのでしょうが。)

    というか、すべてのメールデータが不要ということで、本番環境ではないのかな?と勝手ながら思っていますので、メールボックスごと削除できないですか?

    あと、DBがどの領域に保存されているのかにのよりますが、サーバー上に保存されている不必要なログファイルなどを削除する程度でしょうか。

    ご存知とのことですが、念のため。オフラインデフラグを行っても効果は出ませんか?

    http://support.microsoft.com/kb/328804/ja

    2012年3月1日 23:28
  • 早速のご回答ありがとうございます★

    多少聞きたいことを伝え間違えた気がしますので、再度質問

    したいですが、ご回答よろしくお願いします。

    そもそも「priv1.edb、priv1.stm」の容量を削減するため、手順として

    ①メーラーよりメールデータの受信

    ②オンライデフラグ  

    ③オフラインデフラグ

    と認識しています。

    「①メーラーよりメールデータの受信」のところ、つまりオンラインデフラグ前の段階で、

    メール受信以外に何か方法がございますか?

    お手数ですが、よろしくお願いします!!!

    2012年3月2日 4:57
  • もう少し何がどうなのかを 正確に確認した方が良いかもしれないですね。

    そもそも論。

      Exchange Server にとっての空き容量について。

       priv1.edb / priv1.stm  のデータベースファイルの合計サイズが 10GBだった場合。

       このデータベース内にメールボックスを作成されている10名のユーザー user1 ~ user10 の保持データ量が現時点で9GB だった場合、 

       Exchange Server 的には、データベース内に 1GB の空き容量が空いている、と認識しています。

       この空き容量を増やしたい場合、

        1. 各ユーザーの不要なメールを削除する。(削除済みアイテムフォルダも空にする)

        2. データベースのプロパティの削除済みアイテム保存期間を 0日 にする。 

        3. クリーンアップを実行する。

       という手順で、もし各ユーザーが 100MB ずつ 不要メールを削除してくれていたら、 データベース内に 1000MBの空き容量が増えます。

       priv1.edb / priv1.stm  の物理ファイルサイズは変更されません。 10GBのままですが、内部の未使用領域が広がり、約2GBの空き容量を確保できます。

     メールボックス単位の使用量制限について

       データベースなにがしと関係なく、  user1 に対してメールを送信する 容量不足で弾かれるとか、 user1 がメールを送信しようとすると容量不足で弾かれる というのは

       メールボックスデータベースのプロパティまたは受信者のアカウントのプロパティのどちらかで、 送信を禁止するサイズ、 送受信を禁止するサイズが設定してあり、

       user1 の保持するサイズがその制限値を上回っている可能性があります。

       その場合は、 user1 に不要なメールを削除させる、 か ディスクの空き容量に余裕があるなら、制限値を緩和する。

     物理ディスク領域の不足

       サーバーのデータ領域のハードディスク容量が  100GB で、 データベース容量が 40GBぐらいの場合。

       → 前述の3手順を実施して、そもそもデータベース内部の空き容量(物理的に圧縮されても構わなくなる領域)を広げます。

       1. データベースの完全バックアップを取得します(Exchange Serverデータベースのバックアップに対応しているバックアップソフトでバックアップを実行します)

         バックアップを取得したことにより、データベース内の空き領域が物理サイズとして縮小されていい形にマークされます。

         ※ もしかしたら、クリーンアップを実行する前にバックアップを取った方がより良かったかもしれません。

       2. オフラインデフラグを実施します。

         オフラインデフラグは、元のデータベースサイズx1.2倍の空き容量が必要になる事があります。 40GBのデータベースに対して処理すると 48GBの空き容量が

         ないと失敗する可能性があります。

         この例では、60GB 空き容量があるので実施できることになります。 もし、データベースサイズが 50GB を超えていたら、空き容量が元のデータベースサイズを下回るので

         オフラインデフラグは失敗する可能性が高くなります。

         オフラインデフラグに成功すると、最終的なデータベースの物理サイズが小さくなります。

         物理サイズ 40GB 中 空き容量が 10GB 確保できていたとしたら、 最終サイズは 30GB くらいになる可能性があります。

    メーラーで受信する、の意味するところが Exchange Server 側メールボックスないのデータを全部クライアント側に移す、という事であれば、

    その後にクリーンアップ手順が必要になると思います。

    仮にその Exchange環境が本番環境でなくテスト環境で有り、メールデータその物どうでもいいのであれば、すべてのユーザーのメールボックスを削除して

    すべてのユーザーの Exchange属性もクリアして、 そもそもデータベースを削除して、データベースそのものを作り直す、というのも

    アリかな、とは思います。

    • 回答としてマーク 星 睦美 2012年3月9日 4:37
    2012年3月2日 5:22
  • クライアントからメールを削除しても、削除済みアイテムの保存期間の間は残ってます。

    データベースの保守で、オンラインデフラグをやっても「空き領域」としてマークされたところができるだけで、.edb のファイルサイズは小さくなりません。

    オフラインデフラグをやる場合は、データベースファイルサイズの 1.2 倍以上の空き領域が必要です。

    したがって、大きいディスクを買ってきてそこにデータベースを丸ごと移動しましょう。これが緊急の対応方法として一番現実的です。

    # 一度サービスを止めて、priv1.stm を消す。というのも無きにしもあらずだが。。。

    • 回答としてマーク 星 睦美 2012年3月9日 4:37
    2012年3月2日 8:51
  • ご回答ありがとうございます。いろいろ試してみます。

    2012年3月9日 0:56
  • 了解しました。

    ご回答ありがとうございます★

    2012年3月9日 0:59