今日もまた、SQL Server 2005 でのパラメータ スニッフィングと思われる重大な問題が発生しました。
いくつかの結果を既知の良好な結果と比較するクエリがあります。結果と既知の良好な結果に列を追加して、毎月新しい月の結果を両側に読み込んで、現在の月のみを比較できるようにしました。新しい列はクラスター化インデックスの最初にあるため、新しい月が最後に追加されます。
句に基準を追加します。WHERE
これはコード生成されるため、リテラル定数です。
WHERE DATA_DT_ID = 20081231
-- 現在、すべての DATA_DT_ID が 20081231 であるため、これは冗長です。
パフォーマンスはポットに行きます。約 150 万行を比較するのに 7 秒から 2 時間かかり、何も完了しません。生成された SQL を SSMS で正しく実行する - SP なし。
私は SQL Server を 12 年間使用してきましたが、10 月以降、この運用サーバー (ビルド ビルド 9.00.3068.00) で経験したように、パラメーター スニッフィングでこれほど多くの問題が発生したことはありません。いずれの場合も、最初に別のパラメーターを指定して実行したか、テーブルを変更したためではありません。これは新しいテーブルであり、このパラメーターを使用してのみ実行されるか、WHERE
句がまったく使用されません。
いいえ、私には DBA アクセス権がなく、実行計画を表示するための十分な権限が与えられていません。
ほんの数年の経験しかない SQL Server ユーザーにこのシステムを処理できるかどうか確信が持てないところまで来ています。
UPDATE統計は最新であると主張していますが、UPDATE STATISTICS WITH FULLSCAN を実行すると問題が解消されることがわかりました。
FINAL UPDATE WITH RECOMPILE と UPDATE STATISTICS を使用して SP を再作成しても、NULL チェック付きの LEFT JOIN の代わりに NOT IN を使用するようにクエリを別の方法で書き直す必要があることがわかりました。