SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
ストアドプロシージャを明示的にリコンパイルさせる方法として ストアド プロシージャの再コンパイル に記載されている sp_recompile を使用するという方法があります。
ストアドプロシージャはコンパイル時に指定されたパラメーターによって実行プランが生成されるため、コンパイル時に指定されたパラメーターが大多数の実行に対してマイノリティな設定の場合、頻繁に実行するクエリに対しては効率の悪い実行プランが生成されることがあります。
このような場合は、ストアドプロシージャをリコンパイルさせることで新しい実行プランを生成することがあります。
このリコンパイルを同時実行性の低下をできるだけ抑えて実行するにはどのような方法が考えられるでしょうか。
SSMS からクエリを実行した場合と、アプリケーションからクエリを実行した場合の違いとして、Qiita で書いた アプリから動かすと遅いが SSMS から動かすと速いのは ARITHABORT の違いという情報の動作を理解する というような動作があります。
SET オプションが異なっていると、異なる実行プランとしてキャッシュが行われるため、SSMS とアプリケーションで同一のオプションを使用するというのが記載した内容となります。
この投稿では、「SET ARITHABORT OFF」を SSMS から実行し、アプリケーションと同一の SET オプションの状態とすることで SSMS とアプリケーションで同一のプランキャッシュを使用していました。
クエリの多重実行と SSMS から実行したクエリで同一のプランキャッシュを使用したかったので「SQLQueryStress」と「SET ARITHABORT OFF に設定した SSMS」でクエリを実行したところ、同一のプランキャッシュが使用されないという事象が発生しました。
そこで、同一の SET オプション以外にどのような要因が同一のプランキャッシュが使用されないことにつながっているのかを確認してみました。