.NET Framework 4.0で実行されているWindows Server 2012 Datacenter(IIS 8)にWebアプリケーションがあり、SQL Server 2012で別のWindows Server 2012 Datacenterに接続しています。私のデータベースには、3つのパラメーターUserID、StartDate、および終了日。このストアドプロシージャは非常に適切に実行されますが、月末(すべての+40.000クライアントが使用する場合)にパフォーマンスが徐々に低下し始めます。
奇妙なことに、互換性レベルをSQL Server 2008に変更すると、自動的に "更新"され、非常に高速に動作するようになりました。その後、再び(再び)互換性レバーを2005に戻して動作するようになるまで、パフォーマンスを徐々に低下させました。正しく。
パフォーマンスを徐々に低下させた後、メインストアドプロシージャの互換性レベルを変更すると大幅に向上するのはなぜですか?
これは、SQL Server内のデータベースの互換性レベルを変更したときに影響を受ける変更が原因です。これは、SQL Server 2008以降で見られた影響でした。少なくとも、それ以降はドキュメントに表示されています。
ここMSDNで ALTER DATABASE SET COMPATIBILITY_LEVEL について述べたように:
互換性レベルとストアドプロシージャ
ストアドプロシージャを実行すると、定義されているデータベースの現在の互換性レベルが使用されます。データベースの互換性設定が変更されると、それに応じてすべてのストアドプロシージャが自動的に再コンパイルされます。
したがって、基本的には、現在キャッシュ内にあるすべてのクエリプランが再コンパイル用にマークされていることがわかります。これには、上記のストアドプロシージャが含まれます。そのため、そのストアドプロシージャの計画が再コンパイルされたため、最初のパフォーマンスの向上が見られます。その後、しばらく実行された後、計画は十分ではありませんでした。
互換性レベル間を行き来する代わりに、プロシージャを最適化して、生成されるクエリプランが渡されるパラメーター値の範囲により最適になるようにする必要があります。コードの変更をすぐに実行できない場合の迅速な代替方法は、頻繁に使用するジョブをスケジュールして、プロシージャを最初に再コンパイルするようにマークすることです。
Shawn Meltonに加えて、まだコメントできないため、定期的に統計を更新できます。これにより、新しい実行プランが生成されます。その後、sp_recompile
を使用してストアドプロシージャを再コンパイルします。
ここに素晴らしいスクリプトのリンクがあります: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
パラメータスニッフィングのケースのように見えます!
その上でグーグルをチェックしてください。
これらのコマンドを実行しても同じ効果があります。
DBCC FREEPROCCACHE
このコマンドは、キャッシュされたすべてのクエリプランと実行コンテキストをプランキャッシュから削除します。このコマンドは、実行中のアプリケーションのパフォーマンスに悪影響を与える可能性があるため、運用サーバーで実行することはお勧めできません。このコマンドは、再コンパイルの問題をトラブルシューティングするときに、プランキャッシュの内容を制御するのに役立ちます。
DBCC FLUSHPROCINDB(db_id)
このコマンドは、特定のデータベースのプランキャッシュから、キャッシュされたすべてのプランを削除します。このコマンドは、実行中のアプリケーションのパフォーマンスに悪影響を与える可能性があるため、運用サーバーで実行することはお勧めできません。
DBCC FREESYSTEMCACHE(キャッシュ[、リソースプール])
このコマンドは、特定のキャッシュ内のすべてのプランを削除します。値「ALL」もキャッシュに提供できます。 SQL Server 2008ではオプションで、このコマンドの効果をリソースガバナーのリソースプール名で制限できます。この後者のオプションは、「Sys Plans」キャッシュオプションも提供されている場合、特定のリソースプールに関連付けられているアドホッククエリプランをクリーンアップするのに役立ちます。このコマンドは、実行中のアプリケーションのパフォーマンスに悪影響を与える可能性があるため、その効果を完全に理解していない限り、運用サーバーで実行することはお勧めできません。
これは問題の解決策ではなく回避策です!