web-dev-qa-db-ja.com

クエリプランのキャッシュを更新する必要がありますか

私の問題と状況を説明させてください:

Webアプリケーション-MVC3、MSSQL Server 2005、LinqToSQLがあります。ある晴れた朝まで、頻繁に使用されるテーブルに多くの行をプッシュし、それ以降クエリのタイムアウトが発生するまで、それは非常にうまく機能していました。問題を解決するために、データベースチューニングアドバイザーを実行し、いくつかのインデックスと統計を追加しました。また、毎日インデックスを再構築するメンテナンスプランも作成しました。これらの追加後、アプリケーションは不安定な動作をしてきました。数時間高速で動作し、その後再びタイムアウトします。次に、生命は私に問題のテーブルをクリーンアップすることを余儀なくさせ、その中の行の量は以前よりもさらに少なくなりましたが、タイムアウトはまだ起こっています。そのため、作成したすべてのインデックスを削除しましたが、Webサイトの安定性は大幅に向上しましたが、タイムアウトが発生する場合があります。

私はそれらのクエリを修正する方法を見つけ出そうとしていて、それをプロファイリングしてSQL Management Studioに直接貼り付けると、1秒で結果が返されますが、このクエリをアプリケーションから実行すると、約25秒です。 。その後、初めて実行した後、次回はサーバーと同じ速度で実行されます。

私はいくつかの研究を始めました、そしてそれらすべてのインデックスで遊んだとき、私のクエリプランはめちゃくちゃになり、今それらは問題を引き起こしているようです。

私の質問は:

  1. クエリプランキャッシュを更新する必要があります(約22000クエリ-多くのクエリは1回しか使用されていません)。
  2. それを行うと、SQLがすべて再構築されている間、SQLにどのような影響がありますか?
5
bobek

問題を一歩ずつ見ていきましょう:

ある晴れた朝、使用頻度の高いテーブルに多くの行をプッシュし、それ以来クエリのタイムアウトが発生するまで、それはうまく機能していました。

テーブルに対して大規模な更新/挿入を行う場合は常に、statsを更新し、インデックスを再編成/再構築することを強くお勧めします。こうすることで、クエリオプティマイザーは、誤った推定で不良プランを選択または生成しません。

問題を修正するために、データベースチューニングアドバイザーを実行し、いくつかのインデックスと統計を追加しました。

ワークロードを理解し、推奨事項を適切にテストすることなく、これを実行しないでください。 Aaron Bertrandによる 単に「欠けている」インデックスを盲目的に作成しないでください! を参照してください。

また、毎日インデックスを再構築するメンテナンスプランも作成しました。

インデックスの断片化率を確認し、それに応じてインデックスを再編成または再構築することをお勧めします。最適なのは SQL Serverインデックスと統計のメンテナンス を使用することです。これは、無料で広く実装されている無料のソフトウェアです。

次に、生命は私に問題のテーブルをクリーンアップすることを余儀なくさせ、その中の行の量は以前よりもさらに少なくなりましたが、タイムアウトはまだ起こっています。そのため、作成したすべてのインデックスを削除しましたが、Webサイトははるかに安定していますが、時々タイムアウトが発生します。

同上。これで、オプティマイザに誤った統計が含まれるため、非効率的なクエリプランが作成される可能性があります。ベストはUPDATE STATISTICSで、sp_recompileなので、次回オプティマイザは、利用可能な更新された統計に基づいて新しいプランを生成します。

また読んでください: アプリケーションで遅い、SSMSで速い?

10
Kin Shah

まず、いいえ、おそらくクエリプランのキャッシュをクリアすべきではありません。不正なパラメータスニッフィングに問題がある可能性があります。いろいろな人が書いた記事です。 SimpleTalkを使用するGreg LarsonBrent Ozar Unlimitedを使用するJes Schultz Borland 、および Thomas LaRock 。あなたはクイック検索を行うことができ、他の人のトンが表示されます。それは人気の主題です。

私があなただったら最初にすることは、影響を受ける各テーブルの統計を更新することです。

update statistics TableName;

次に、影響を受けるテーブルでsp_recompileを実行します。これにより、そのテーブルに関連付けられているすべてのストアドプロシージャが再コンパイルされます。これにはある程度の影響がありますが(後で説明します)、キャッシュ全体をクリアするよりも優れています。

EXEC sp_recompile Table;

クエリプランのキャッシュをクリアするか、最適化プログラムを再コンパイルするストアドプロシージャをマークすると、そのコードのプランを再作成する必要があります。もちろんこれには時間がかかります。また、アクティブなシステムがある場合、キャッシュを完全にクリアすると、すべてが再作成されている間、システム全体の速度が低下します。もちろん、各クエリ/ SPは、使用されるときにのみ再作成されます。

7
Kenneth Fisher