監査ログの削除はときとして大事。stsadm -o trimauditlog

コンテンツデータベースの実サイズ容量がシステム管理者の皮膚感覚よりも随分大きい場合、監査ログを疑った方が良いかもしれません。

SharePoint の監査ログはコンテンツデータベース内の「AUDIT」テーブルにストアされますが、注意点は、監査ログ機能を利用していなくてもログは溜まる、ということです。

SharePoint は「情報管理ポリシー」の動作ログを、このテーブルに記録します。そのため、このログデータの扱いをきちんと計画しておかないと、気が付けば壮絶な量のログにデータベースが埋め尽くされることになりかねません。
(※実際にはそれ以外のログも蓄積されている気もしますが未確認です)

私自身が遭遇した事例では、3億行のデータが蓄積されているケースがありました。このログが占める容量を正確に測定することは出来ないのですが、いちページはデータベースの内部的に8キロバイトに相当するため、そこから単純計算で約50GB。必ずしも隙間なくデータが並んでいる訳ではないため、実データはより大きくなることが考えられます。

さて、この監査ログを削除するには stsadm コマンドが必要です。

例:2010年01月01日までの監査ログを削除
stsadm -o trimauditlog -date 20100101 -databasename WSS_Content

例:2010年10月14日までの監査ログを削除
stsadm -o trimauditlog -date 20101014 -databasename WSS_Content

ただ、このコマンドを実行しても一向に削除が完了しないこともあります。環境次第ではあるのですが、実績として、膨大な量の監査ログの削除には、相当な時間(数十時間)を要することがあるようです。

そのため、上のコマンドの日付オプションを利用し、数日~数週間を範囲にして徐々に削除してゆくことをお勧めします。

また、データベースのトランザクションログに割り当てられた容量も注意点です。
ログをシンプルモードで運用している場合、通常はほとんどログが溜まらないためこの値が低く設定されていることが多いのですが、この stsadm コマンドの実行時には、モードによらず大量のログが生成されるようです。

このため、十分な領域が確保されていないと自動拡張が実行され、それがディスク圧迫やサーバーへの負荷をかけることで余計に遅くなり…という悪循環に陥ります。

そもそも一括でパージできれば良いのですが、残念ながら ShrePoint の仕様でそれは出来ないようです。


Author

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

FaceBook Activity