問題タブ [parameter-sniffing]

SQL Server 2008 R2 に対して実行されている Entity Framework (4.2) によって生成された単純な SQL クエリで、重大なパフォーマンスの問題が発生しています。一部の状況 (すべてではない) では、EF は次の構文を使用します。

他の状況では、提供されたパラメーターをクエリに焼き付けて生の SQL を実行するだけです。私が遭遇している問題は、sp_executesql で実行されたクエリがターゲット テーブルのすべてのインデックスを無視しているため、クエリのパフォーマンスが非常に低下していることです (SSMS で実行プランを調べることで確認されています)。

少し調査した結果、この問題は「パラメータ スニッフィング」が原因である可能性があるようです。OPTION(RECOMPILE) クエリ ヒントを追加すると、次のようになります。

ターゲット テーブルのインデックスが使用され、クエリは非常に高速に実行されます。また、データベース インスタンス ( http://support.microsoft.com/kb/980653 ) でパラメーター スニッフィング (4136) を無効にするために使用されるトレース フラグを切り替えようとしましたが、これはまったく効果がないようです。

これにより、いくつかの質問が残ります。

1. Entity Framework によって生成された SQL に OPTION(RECOMPILE) クエリ ヒントを追加する方法はありますか?
2. Entity Framework が exec sp_executesql を使用するのを防ぎ、代わりに生の SQL を実行する方法はありますか?
3. 他の誰かがこの問題に遭遇していますか? 他のヒント/ヒントはありますか？

追加情報：

1. SSMS を介してデータベース インスタンスを再起動しましたが、サービス管理コンソールからサービスを再起動してみます。
2. パラメータ化は SIMPLE に設定されます (is_parameterization_forced: 0)
3. アドホック ワークロードの最適化には、次の設定があります。
   • 値: 0
   • 最小: 0
   • 最大: 1
   • 使用中の値: 0
   • is_dynamic: 1
   • is_advanced: 1

また、以下のスクリプトでトレース フラグ 4136 を有効にした後、サービス管理コンソールを介して SQL Server サービスを再起動すると、実際にはトレース フラグがクリアされているように見えることにも言及する必要があります...おそらく、これを別の方法で行う必要があります...

更新: EF の将来のバージョンでヒント コントロールを実装するための提案を作成しました。ここに行って投票してください。

Entity Framework (EF) クエリの 1 つが Sql Server で実行するのに非常に長い時間がかかるという問題がありますが、生成された TSQL をコピーして Sql Server Management Studio (SSMS) に貼り付けると、非常に高速に実行されます。調査の結果、パラメーター スニッフィングの問題が発生していることがわかりました。これを修正する正しい方法は、多くのクエリ ヒント (OPTIMIZE FOR、RECOMPILE など) の 1 つを挿入することです。これらのヒントを EF クエリに挿入するにはどうすればよいですか?

さまざまな観点からの関連する質問は、ここ、ここ、およびここにあります。

ストアド プロシージャを繰り返し実行する次のコードがあります。SQL ステートメントを文字どおりに実行するとうまく機能するので、実行していることをカプセル化したストアド プロシージャを作成しました。

次に、各呼び出しが生成する行数を知りたかったので@@rowcount、出力パラメーターとして返すように SP を少し変更しました。DataContext を使用して出力パラメーターを使用してコマンドを実行することはできないため、上記の for ループ内のコードを次のように変更する必要がありました。

これは機能しますが、他のクエリよりもはるかに遅く実行されます。パラメータ盗聴のケースかもしれないと思ったのでCommandType.Text、文字列に変更して使用しましたEXEC Session_Aggregate ... WITH RECOMPILE。しかし、その場合、out パラメータ@sessionが定義されていないというエラーが表示され続けます。いずれにせよ、SQL コマンドは SSMS で 1 秒未満で実行されますが、クエリはほとんど実行されません。

誰かが何が起こっているのかを理解するのを手伝ったり、物事をスピードアップする方法を見つけたりできる場合に備えて、ストアド プロシージャを次に示します。また、ここで何が起こっているかを適切にプロファイルする方法についての指針も示します。CommandType.StoredProcedureVSによってSQLに送信される実際のコマンドを見ることさえできません。

編集:元のクエリの実行計画に関係なく、一時テーブルを作成することで大幅に高速化されました。クエリを分析することで SQL がこれを行うと思っていましたが、おそらく間違っていました。また、 SQL Server の新しいバージョンでは、実行プランが非常に異なるサイズのデータ​​に対するパラメーター スニッフィングの影響を軽減するヒントを発見しました。OPTIMIZE FOR UNKNOWN

追加の簡素化: SP を DBML ファイルにドラッグすると、次のことができます。

I have a multi-tenant database in SQL Server 2012 where each tenant's rows are identified by a tenant_id column (aka the Shared Database, Shared Schema approach). Some tenants, particularly the newer ones, have very few rows, while others have many.

SQL Server's query optimizer normally builds a query plan based on the parameters provided during its first execution, then re-uses this plan for all future queries even if different parameters are provided. This is known as parameter sniffing.

データベースの問題は、SQL Server が小さなテナントを指すパラメーターに基づいてこれらのプランを構築することがあり、そのテナントでは問題なく機能しますが、キャッシュされたプランを大きなテナントに再適用すると壊滅的に失敗することです (通常はタイミング実際、アウト）。通常、この状況は、大規模なテナントの 1 つからタイムアウト エラーの発生について問い合わせがあった場合にのみわかります。その後、システムに入り、すべてのクエリ プランを手動でフラッシュして修正する必要があります。

SQL Server がクエリ プランをキャッシュしないようにするために使用できるクエリ ヒントがあります ( OPTIMIZE FOR UNKNOWN) が、クエリが呼び出されるたびにクエリ プランが再生成されるため、追加のオーバーヘッドが発生します。追加の問題は、OPTIMIZE FOR UNKNOWNクエリでヒントを指定する機能を提供しない Entity Framework を使用していることです。

問題は、パラメータ スニッフィングに関するマルチテナント データベースのベスト プラクティスは何かということです。すべてのクエリで指定することなく、データベース全体でパラメーター スニッフィングを無効にする方法はありますか? もしそうなら、それは最善のアプローチですか？他の方法でデータを分割する必要がありますか? 私が考えていない他のアプローチはありますか？

約70個のパラメータを使用した更新クエリがときどきタイムアウトするという問題があります。いくつかの調査に基づくと、これはパケットスニッフィングによるものだと思います。新しいバージョンのSQLServerではこのOption(recompile)句を使用できますが、サーバー2000を使用しているため、私の場合は機能しません。

sqlhelper.executeNonQueryストアドプロシージャではなく、使用しています。

テーブルに対して sp_recompile を実行すると、そのテーブルに依存するすべてのストアド プロシージャとトリガーが再コンパイルされることを理解しています。

私が理解していないのは、SQL Server がこの再コンパイルに使用するパラメーターです。ここでは、パラメーター スニッフィングがどのように考慮されるかわかりません。OPTIMIZE FOR UNKNOWN に似たものを使用して「一般的な」実行計画をコンパイルしますか?

本当に明白な何かが欠けているように感じます。

誰もこれについて理解していますか？

パラメータ スニッフィングに関する多くの記事を読みましたが、これが良いか悪いかは明確ではありません。誰でも簡単な例でこれを説明できますか。

間違った計画が特定のステートメントに割り当てられたことを自動的に検出する方法はありますか?

前もって感謝します。