「パラメータースニッフィング」によって、あるタイミングから処理が遅くなった（パフォーマンストラブル）：SQL Serverトラブルシューティング（51）（2/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「あるタイミングで処理遅延が発生し、それが継続して発生するようになってしまった場合の対処例.2」を解説します。

[椎名武史，ユニアデックス株式会社]

解決方法

　今回は、パラメータースニッフィングによって、適切でないパラメーターで作成された実行プランがキャッシュされていたために処理遅延が発生しました。このため、「適切なパラメーター」で作成した実行プランをキャッシュするように再調整することでトラブルは解決できます。

　具体的には、SQL Serverを再起動して「キャッシュをクリアする」、あるいは「sp_recomple（*2）を使って、次回実行時に実行プランを再作成する」ことで、この時に使ったパラメータを用いた実行プランを作成できます。

EXEC sp_recompile N'sp1'

対象ストアドプロシージャ「sp1」の実行プランを再作成する「sp_recomple」コマンドの例

参考リンク *2：sp_recompile（Transact-SQL）（Microsoft Developer Network）

　しかし、この対処だけでは再発する可能性が残ります。そこで恒久的な対処方法として勧められるのは、「（特定の値ではなく）一般的な値で実行プランを作成する」ことです。

　具体的には、スタートアップオプション（*3）として、レジストリに「;-T 4136」を追加すると、実装されている全てのパラメーターは「一般的な値で実行プランが作成」されます。特定のクエリだけに設定する場合には、クエリヒント「OPTIMIZE FOR UNKNOWN」（*4）を使用することでも、一般的な値で実行プランを作成できます。

　この他には、「RECOMPILE」というクエリヒントを使用して毎回実行プランを作成する対処方法もあります。

参考リンク *3：データベース エンジン サービスのスタートアップ オプション（Microsoft Developer Network）

参考リンク *4：クエリヒント（TRANSACT-SQL）（Microsoft Developer Network）

「パラメータスニッフィングによって、あるタイミングから処理が遅くなった」場合の対策手順

1. キャッシュされている実行プランが使用したパラメータを確認する
2. SQL Serverの再起動、もしくは「sp_recompile」などで必要なパラメータを使用した実行プランを作成する
3. トレースフラグ「4136」、もしくは「OPTIMIZE FOR UNKNOWN」「RECOMPILE」などでパラメータースニッフィングが発生しないように変更する

目次に戻る

本トラブルシューティングの対応バージョン：SQL Server全バージョン

筆者紹介

内ヶ島 暢之（うちがしま のぶゆき）

ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP Data Platform（2011〜）。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、2016年現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。

椎名 武史（しいな たけし）

ユニアデックス株式会社所属。入社以来 SQL Serverの評価／設計／構築／教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。