WSS_Content_log の肥大化にご用心

わたしのMOSS環境ですが、単一のサイトコレクションで、WSS_Contentの容量が160GB…何かがおかしいのです。確かに、サイトは既にユーザに公開されており、多くのファイルが登録されています。しかし、こんな短期間に100GBを越すとはちょっと考えにくい。せいぜい数十GBではないか?しかし、WSS_Content のサイズは厳然たる事実です。

長らく、この感覚と実サイズの違和感に悩んできたのですが、先日の事件(→WSS_Content の自動拡張プロパティにご用心) のお陰で(?)、その原因が判明しました!

元凶は、WSS_Content 内にある WSS_Content_log。トランザクションを記録しているログファイルが削除運用されていなかった結果、100GB以上に肥大化していました。

近日中に、ログを一掃(削除)してしまうつもりです。

トランザクションログの削除方法はこちらを参考。

データベースのバックアップとリカバリの克服 第3回
トランザクションログの切捨て
トランザクションログファイルのバックアップを実行すると、ログの切捨てが行われます。しかしトランザクションログ管理が不要な全体バックアップ戦略を採用している場合は、「ログの切捨て」だけを行いたい希望があります。
トランザクションログのバックアップを実行せずに、ログだけを切り捨てたい。
そのような要望を実行するSQL文が、
BACKUP LOG データベース名
WITH TRUNCATE_ONLY
の命令です。
この命令を実行すれば、「ログの切捨て」が即座に実行されます。

WSS_Content の自動拡張プロパティにご用心
Sharepoint_config_log の肥大化にもご用心


これまでのコメント

  1. chaotzu より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
    それよりも、復旧モデルをシンプルにすべきでしょうね。
    http://msdn2.microsoft.com/ja-jp/library/ms189275.aspx

    結構\SQLの管理を蔑ろにしているお客様が多く、同じ問い合わせがきます。

  2. saruhiko より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 2.0.50727) Sleipnir/2.5.12
    コメント、ありがとうごさいます!
    ・・・白状すると、ご指摘の意味が判らず、社内のSEさんに聞いてきました(笑)
    以下、そのSEさんのコメントです。

    トランザクションログの復旧モデルのことですね。トランザクションログのバックアップのモデルとして「フル」、「一括ログ」、「シンプル」の3種類のモデルが存在します。現在、我々のMOSS環境では「フル」になってます。
    SQLサーバーの保守計画(バックアップ設定)を設定すると、定常的のトランザクションログを削除できるのですが、「統合バックアップ」を運用しているので、我々のMOSSでは運用していません。なので、トランザクションログが肥大化してしましました。
    「統合バックアップ」でもトランザクションログを削除できるらしいので、今後、統合バックアップにて対応しようと画策中です。

    とのこと。
    つまるところ、見落としていた…ということですね(苦笑)
    ご指摘ありがとうございます。

  3. chaotzu より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
    暗号のようなコメントだったようですみません。このサイトはよく参考にさせていただいてるので、もうすこし口を出すと。。。

    50%合っています
    この問題を「バックアッププラン」とするのはどうかと思います。

    そもそもトランザクションログとデータ復旧計画は密接なので、ここをどう考えるかでして、「毎日バックアップを取っていて、そこに戻ればいい」という復旧プランもあれば、障害30分以内のデータまでロールフォワードする必要があるというクリティカルシステムもあるわけです。 
    後者の場合、DB(edb)のリストア+30分毎のトランザクションログをロールフォワードとなります。
    前者の場合、トランザクションログ自体使いません(正確には使うんですが、使わないと言ってしまった方が理解しやすい)
    更新はedbに即座に反映されるので、MOSS上のデータを削除してもトランザクションログが増えるということはないのです

    つまり、1日1回フルバックアップというプランの場合、復旧モデルをフルにしている意味はないのです。

    ここらへんを少し理解すると、今saruhikoさんの環境で実装していると思われるstsadmだけでも運用可能\ですね。(DBのバックアップは必須ではない/システムDBはMonthlyくらいでは必要でしょうけど)

  4. saruhiko より:

    AGENT: *Internet Explorer
    コメントありがとうございます!
    むむむむ…難しいですね(笑)
    SEさ〜ん、かま〜ん(笑)

  5. イケメン より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 3.0.04506.30; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648) Sleipnir/2.7.0
    こんばんわ。何気に酔いが醒めてみてます。
    1日1回、トランザクションログの切り捨てを行う運用になる予\定です。自動拡張等の設定はそのままで、というか置いといて、とうとうHDDの残容量が20GB割って切迫したので、切り捨てを、とっととEnterpriseManagerよりポチります。週末に。SP1適用の例のMS手引きにも「まずは削除しておいてちょ」、って書いてあるらしい。

  6. chaoztu より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
    恥ずかしい。今Exchangeの案件やっていて間違えました。 修正:edb→mdf

login

Author

中村 和彦(シンプレッソ・コンサルティング株式会社 代表)が「ユーザ視点の SharePoint 情報」を発信します。元大手製造業 SharePoint 運用担当。現SharePoint コンサルタント。お仕事のお問い合わせはこちらまでお願いします。当ブログにおける発信内容は個人に帰属し所属組織の公式発信/見解ではありません。
Twitter : @saruhiko
FB : 中村 和彦
MS MVP SharePoint 2009/10-2011/9
MS MVP Office 365 2012/10-

FaceBook Activity