SharePoint サーバーの突発的高負荷は統計情報の再作成で回復する、こともある

決して一般的な障害ではないものの、SharePoint 環境において、突然、データベースサーバが過負荷状態に陥りサービスダウンする、という問題が発生することがあります。この原因は直接のトリガは定かではないのですが、実例としての「解決策」だけは明確です。

この障害は、まったく予期できないタイミングで発生します。コンテンツデータベースのあるサーバの CPU 使用率が突然「天井」状態になり、そのため SharePoint が事実上サービスダウンします。一旦こうなってしまうと、なかなか回復できません。

しかし、いくつかの事例では明確な回復手段があります。

解決策：コンテンツデータベース（SQL）の統計情報の再作成を実行する

これで、魔法のように負荷がおちつきます。

統計情報（statistics）は SQL データベースがデータアクセスを効率化する為に自動的に作成するインデックスです。ある意味、データベースという仕組みの中核部分と言えるかもしれません。（注：私は SQL エンジニアではないため、適当な説明です）

例えば、コンテンツに非常に大きな変更（削除など）が加えられた場合、既存の統計情報ではアクセスが非効率になります。そこで、SQL サーバは自動的に統計情報を更新します。そのため、普段の運用でユーザーが統計情報を意識することはありません。

しかし…ここがよく判らないところのですが、統計情報がほぼ最新で、SharePoint のコンテンツにもほとんど変更が加えられていない筈の状況（例えば深夜に更新が行われた翌日の朝など）でも、この高負荷が発生することがあります（ありました）。

この原因については、かなり追求したのですが、どうしてもトリガーが判らず、残念ながら不明のままです。

SharePoint と統計情報に関して言えば、実は SharePoint 2010 はタイマージョブで定期的に統計情報を更新しています。そのため、SQl 側では統計情報の自動更新はオフに設定することが推奨されおり、既定でオフになっています。

一方、SharePoint 2007 にはこのタイマージョブがありません。そのため、こちらは SQL 側の機能に依拠していて、既定はオンです。

ところが、SharePoint 2007 も SP2 で統計情報を更新するタイマージョブが実装されました。すると、データベース（SQL）側とタイマージョブ（SharePoint）側で更新のバッティングが懸念されます。実際、タイマージョブ側を止めた、という話もあるようです。

参考：
Optimizing SQL for SharePoint
Storage and SQL Server capacity planning and configuration (SharePoint Server 2010)

もしこれが関係しているとすると「SP2 を適用した SharePoint 2007 環境」と「SharePoint 2007 からバージョンアップした 2010 環境」が危ないかもしれませんね。

その他の点としては（サンプリング数が少ないためあくまで皮膚感覚ですが）、コンテンツ（アイテムやファイル）が大量に登録されていて、かつあちこちに個別権限が設定されているサイトコレクション（を含むコンテンツデータベース）が危険であるような気がします。

皆さんの環境では如何でしょうか？もし同じような事例、あるいは関連した情報、あわよくば原因と解決策（笑）などありましたら、ぜひコメント頂けると嬉しいです。

追記：2012/9/30
SQL MVP の Masayuki Ozawa さんが 2010 について検証して下さいました。テーブル/クエリレベルまでの詳細な解説は必見です。
SEの雑記：SharePoint 2010 の Health Analyzer とデータベースのメンテナンスについて