MOSS 2007 SP3 適用に伴う問題

特定の条件において、MOSS 2007 SP3 適用時に構成ウィザードの実行に非常に長い時間を要するとともに、検索データベースのトランザクションログが肥大化する症状が報告されています。

[背景]

MOSS 2007 では大量のコンテンツをクロールする際に、クロールキューに溜まったデータを一括ですべて処理できないため、バッチ処理としてある程度のまとまりごとに処理を行います。この時、内部でバッチ ID を割り振って検索データベースの MSSBatchHistory テーブルにデータを格納して管理するのですが、既知の制限として、MSSBatchHistory テーブルの情報がリセットされず、BatchID が int 型の制限を超えてしまいクロールに失敗するという問題がありました。このため、2011 年 4 月の CU でこの問題が修正されています。

この修正では以下の修正が施されています。

・MSSBatchHistory テーブルの BatchID カラムのデータ型を Int 型から BigInt 型に変更します。

・クロール毎に MSSBatchHistory テーブルをリセットするようになりました。

[問題点]

この修正の影響により、SP3 を含む、2011 年 4 月の CU 以降の修正を適用した場合、構成ウィザード実行時に BatchID カラムのデータ型が Int 型から BigInt 型に変更されるため、MSSBatchHistory テーブルが肥大化している環境では構成ウィザードの実行に非常に長い時間を要するとともに、検索データベースのトランザクションログが肥大化する問題に遭遇する可能性があります。

[対応策]

以下の SharePoint Escalation Services チームのブログにこの問題に対する対応策が紹介されています。

SharePoint 2007: SSP upgrade issue with SP3

https://blogs.msdn.com/b/spses/archive/2012/10/01/sharepoint-2007-ssp-upgrade-issue-with-sp3.aspx

基本的には、可能な限り時間を短縮するための対応策を施すとともに、実施にあたって十分な時間的余裕と、ディスクの空き容量を確保いただくことをお奨めしています。

(概要)

1. 予め MSSBatchHistory テーブルの大きさを確認する

2. upgrade ログのチェックポイントを確認する

3. MSSBatchHistory テーブルのサイズによっては十分なメンテナンスプランの時間を設ける

4. SSP 検索 DB の SQL 復旧モードを「シンプル」に変更する

5. SSP 検索データベース用のトランザクションログの配置先ディスクに十分な空き容量を確保しておく

6. SQL Server の設定で MAXDOP =1 に設定しておく

SharePoint の長期運用において、SP 適用は避けて通れませんので、是非とも頭の片隅に置いておいていただけると幸いです。。