パフォーマンスのチューニングと最適化 (フルテキスト検索)

更新 : 2006 年 4 月 14 日

フルテキスト インデックス作成とフルテキスト クエリのパフォーマンスは、メモリ、ディスク速度、CPU 速度などのハードウェア リソースの影響を受けます。

フルテキスト インデックス作成のパフォーマンス

フルテキスト インデックス作成のパフォーマンス低下の主な原因となるのは、ハードウェア リソースの制限です。

• MSFTESQL サービスと SQL Server の CPU 使用率が 100% に近くなっている場合は、CPU がボトルネックになっています。
• ディスク待ちのキューの長さが平均でディスク ヘッド数の 2 倍を超えている場合は、ディスクがボトルネックになっています。この場合の主な回避策は、作成するフルテキスト カタログを SQL Server のデータベース ファイルやログから切り離し、ログ、データベース ファイル、およびフルテキスト カタログを別々のディスクに配置することです。そのほか、高速なディスクを購入したり RAID を使用することも、インデックス作成のパフォーマンス向上に役立ちます。
• 物理メモリが不足していて (3 GB 以下)、クロール ログにサービス中断メッセージが見られる場合は、メモリがボトルネックになっています。この問題の解決方法については、「Microsoft Full-Text Engine for SQL Server (MSFTESQL) サービスの一時停止」を参照してください。MSFTESQL サービスでは AWE がサポートされていません。4 GB を超えるメモリを追加しても、改善できるのは SQL Server 側のパフォーマンスのみです。

システムでハードウェアのボトルネックが確認されない場合は、ハードウェアの能力を最大限に活用できるようにシステムの微調整を行います。ハードウェアのボトルネックがない場合、Microsoft SQL Server 2005 におけるフルテキスト検索のインデックス作成パフォーマンスは、主に以下の条件に左右されます。

• SQL Server がフルテキスト バッチの作成にかかる時間
• MSFTESQL サービスがバッチを処理する速度

最高のパフォーマンスを得るためには、SQL Server と MSFTESQL サービス間で行われる処理をチューニングする必要があリます。SQL Server がサービスの処理能力以上のバッチを生成した場合、MSFTESQL サービスは一時停止し、その一時停止状態を示すクロール ログ メッセージを生成します。この問題の解決方法については、「Microsoft Full-Text Engine for SQL Server (MSFTESQL) サービスの一時停止」を参照してください。

一方、MSFTESQL サービスをビジーな状態に保っておくだけのフルテキスト バッチを SQL Server が生成しない場合、サービスはアイドル状態となります。これも最適な状態ではありません。実際、この状態は、インデックス作成の実行速度が遅い原因として最も一般的です。MSFTESQL サービスの使用状態が最適になるように、次のカウンタを追跡してチューニングを行う必要があります。

• 進行中バッチ カウンタ : Microsoft Full-Text Engine Filter Daemon (MSFTELFD)
  このカウンタは、システム内の CPU の数と等しいか、2 倍にします。CPU の使用率が低く、値が 0、1、または 2 の場合、SQL Server が有効に実行されていないことを示します。たとえば、4-way コンピュータを使用している場合、この値は 4 から 8 の間にします。
• キュー内のバッチ数 : MSFTESQL サービス

この値は、クロール範囲の数の 10 倍に近い値である必要があります。テーブルのインデックス作成に使用されている範囲の数を特定するには、sys.dm_fts_population_ranges からクエリを実行します。

カウンタの値が小さい場合は、次の方法で改善できます。

• テーブルに複数のクロール範囲があることを確認します。これを確認するには、sys.dm_fts_population_ranges のクエリを実行します。クロール範囲の数は、CPU の数の 2 倍であるのが理想的です。クロール範囲は、テーブルの行の数、CPU の数、および max full-text crawl range 構成オプションによって制限されます。このオプションを有効にするには、クロール操作を再起動する必要があります。

  メモ :
  これは、全体のクロールにのみ適用されます。

• ベース テーブルにクラスタ化インデックスがあることを確認します。クラスタ化インデックスの最初の列には整数データ型を使用します。GUID は使用しないようにしてください。クラスタ化インデックスで複数の範囲のクロールを使用すると、クロール速度を最大限に高めることができます。
• UPDATE STATISTICS ステートメントを使用してベース テーブルの統計を更新します。さらに重要な点は、クラスタ化インデックスの統計や全体のクロールのフルテキスト キーを更新することです。これにより、複数の範囲のクロールによってテーブルに適切なパーティションが生成されるようになります。
• 増分作成のパフォーマンスを強化するには、タイムスタンプ列のセカンダリ インデックスを作成します。

メモ :
増分、手動、および自動の変更追跡による作成は、全体のクロールとは違って、ハードウェア リソースを最大限に活用して処理を高速化するようには作られていません。このため、これらのチューニングのヒントでは、フルテキスト インデックス作成のパフォーマンスを強化できない場合があります。

フルテキスト クエリのパフォーマンスを向上させるための推奨事項

フルテキスト クエリのパフォーマンスを向上させるための推奨事項を次に示します。

• ALTER INDEX REORGANIZE を使用してベース テーブルのインデックスの断片化を解消する。
• ALTER FULLTEXT CATALOG REORGANIZE を使用してフルテキスト カタログを再構成する。このステートメントを実行するとそのカタログのフルテキスト インデックスがマスタ マージされるため、この作業はパフォーマンス テストの前に行うようにしてください。
• フルテキスト キー列の選択を小さい列に制限する。900 バイトの列がサポートされていますが、このようなサイズのキー列を使用してフルテキスト インデックスを作成しないことをお勧めします。
• 複数の CONTAINS 述語を 1 つの CONTAINS 述語に統合する。SQL Server では、CONTAINS クエリに列の一覧を指定できます。
• フルテキスト キーまたは順位情報だけが必要な場合は、CONTAINS または FREETEXT の代わりにそれぞれ CONTAINSTABLE または FREETEXTTABLE を使用する。
• 結果を制限してパフォーマンスを向上させるには、FREETEXTTABLE および CONTAINSTABLE 構文の TOP_N_BY_RANK オプションを使用する。この方法は、すべてのヒットを必要としない場合に使用してください。
• フルテキスト クエリ プランをチェックして、適切な結合プランが選択されていることを確認する。必要であれば結合ヒントやクエリ ヒントを使用します。フルテキスト クエリでパラメータが使用されている場合は、パラメータの初回の値によってクエリ プランが決定されます。OPTIMIZE FOR クエリ ヒントを使用すると、クエリのコンパイルに使用される値を強制的に指定できます。これにより、決定的なクエリ プランを実現してパフォーマンスを強化できます。

参照

概念

フルテキスト検索の管理

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース	履歴
2006 年 4 月 14 日	変更内容 : パフォーマンス チューニングのヒントを大幅に修正しました。