SharePointの増分クロールが予定時間を大幅に過ぎても終わらない原因

SharePointに限らず、検索クロール（インデックス）にかかる時間は、基本的にコンテンツ量に比例します。コンテンツ容量、よりもむしろオブジェクト数と考えるべきですが。そのため、運用が軌道に乗ると、ある程度クロールにかかる時間は事前予想できるようになります。

しかし時折、この想定時間を大幅に過ぎてもクロールが完了しないことがあります。それも数十分レベルではなく数時間の誤差で。厄介なことに、クロール対象のコンテンツ数は普段と大差ありません。サーバを確認しても異常な負荷はなく、逆に本当にクロール中なのか疑いたくなるレベルです。また各種ログを見ても、クロールが進行している形跡が見られません。

こうなるとシステム担当者としては当然「クロールがハングアップしているのでは？」と疑いたくなります。しかし、実は大抵の場合、クロールは正常に進行中なのです。この原因はコンテンツのアクセス権設定が大きく変更されたことによります。クロールがコンテンツではなくそのセキュリティ情報だけをひたすら更新しているのです。このクロールを「セキュリティクロール」と呼びます。

この仕様を、日本マイクロソフトのSharePointサポートチームの方が非常に仔細に、原理から確認方法まで解説されていますのでご紹介します。

Japan SharePoint Support Team Blog > セキュリティ クロールについて
http://blogs.technet.com/b/sharepoint_support/archive/2011/10/14/3459245.aspx

セキュリティ クロールの特徴は次の通りです。
・セキュリティ クロールは増分クロール時にのみ実施される。(フル クロール時にはセキュリティとコンテンツ内容の両方がクロールされるためセキュリティのみのクロールは発生しない。)
・クロールは内部的に行われるため実コンテンツへのアクセスは発生しない。従って、IIS ログにはコンテンツに対するクローラーのアクセス ログは残らない。
・Gataherer は SQL Server との通信により検索インデックスへのセキュリティの変更を完了させる。(検索インデックスのアクセス権は検索データベースで管理される。)
・セキュリティ クロールはコンテンツ数に比例してその処理時間が増加する傾向となる。
・実ファイルに対するクロール処理 (フィルタ処理) が発生しないため、クロール ログが記録されない。

運用担当としては必読です。

ただ、厄介なことにこの仕様を理解しても、トリガが「アクセス権の設定変更」というごく普通のアクションですので、事実上、防ぎようがありません。「そういうもの」として増分クロールのスケジュールを設計するしかありませんね。