web-dev-qa-db-ja.com

SQL Serverは毎日計画を再作成します

実稼働環境でこの問題があります。

Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-Windows NT 6.1（Build 7601：Service Pack 1）上のEnterprise Edition（64ビット）。

SQL Serverは古い実行計画のすべて（ほぼ100％）を削除し、毎日夜間（11:00 PM to 8:00 AM）に再作成します。これは、「自動「統計の更新」は無効な状態でした。過去2〜3週間は「統計の自動更新」をオンにしていますが、まだ実行中です。

このプランの再生成をトリガーするものは実際にはわかりませんが、手動で行わないことは確かです。

計画が再生成されるタイミングと本当に一致するのは、DBメンテナンスジョブのみです。これは、毎日のインデックスの再編成（断片化が5〜30％の場合）と毎日のインデックスの再構築（断片化が30％を超える場合）です。 ）仕事。通常、この毎日のメンテナンスジョブは再編成のみを行います（インデックスの断片化は毎日30％を超えることはないため）。

影響：

これらの新しく作成されたプランは、一部のUDF呼び出し/クエリ呼び出し（UI/Webページから呼び出される）にかかる時間を長く（1秒未満ではなく数分）するため、セッションが積み重なってCPUが90％近くになる。

問題は、スタックされたセッションが（DB側で）強制的に削除されたとき、および1）対応するすべての実行プランが手動で（クエリの場合）クリアされたとき、または2）UDFが変更されたとき（関数の場合）に解消されます。その瞬間からSQLサーバーによって作成された新しい計画は、翌朝同じ問題が発生するまで、一日中完璧に機能します。また、この動作は100％一貫しているわけではなく、毎朝実際に見られるわけではありません。しかし、それが4〜5日間続けて見られる期間がありました。

問題は朝の朝に発生します。それは、UI/Webページがより集中的にアクセスされるときだと思われます。

これを引き起こしている原因とこの問題を解決する方法を知る手がかりはありますか？助けていただければ幸いです。

sql-serversql-server-2008execution-planstatistics
14
peter.petrov

まあ私はこの動作を引き起こす可能性があるいくつかのアイデアを持っています。

  1. あなたの記憶圧を監視していますか？たぶんあなたのクエリは、プランのキャッシュのフラッシュを引き起こす特定の制限を引き上げます。私はあなたのアプリケーションを知りませんが、これはあなたのフロントエンドサーバーからのログと一致していますか？この間もプレッシャーはありますか？
  2. 専用のSQL Serverを持っていますか、それともサーバーはそのハードウェアを他のプロセス/サービスと共有していますか？そうでない場合は、代わりにSQL Serverを専用マシンに外部委託することを検討してください。これは他のサービスからの副作用を減らします。
  3. optimize for ad hoc workloadsを使用すると、プランスタブが保存され、必要に応じてコンパイルされます。これにより、プランキャッシュの負荷が軽減され、プランキャッシュがフラッシュする可能性が低くなります。 sp_configure 'optimize for ad hoc workloads',1; reconfigureを使用して有効にできます。これは、advanced optionsを使用してsp_configure 'show advanced options',1; reconfigureを有効にしている場合に実行できます。
  4. 別のアイデアはバックアップです。単純なバックアップ。それらが積極的である場合、あなたのマシンもプレッシャーにさらされる可能性があります。あなたが言及した時間は、バックアップを計画するための良いタイムスパンのように聞こえます。
  5. 多分それはあなたのメンテナンススクリプトのバグは非常に簡単です。基準に一致するものだけでなく、スクリプトがすべてのインデックスを再構築する論理的な問題があるかどうかを確認しましたか？これも原因かもしれません。

これらすべての可能性に加えて、オプションaffinity mask、affinity I/O maskとそれらのx64パートナーに対するいくつかの変更についてログファイルを確認すると役立つ場合があります。もう1つは、インスタンスのMAXDOPオプションの変更です。それらのログも確認してください。彼らはまた、プランキャッシュをフラッシュする必要があります。

最後に重要なことですが、サーバー側のトレースを実行することもできます（プロファイラーを使用して設定し、開始して停止し、sqlコマンドを使用してサーバー側で再度開始します）。 perfmonはあなたの友達です。一定期間のパフォーマンス値を監視できます。多分あなたは、それらのフラッシュを引き起こす可能性のあるあなたのサーバーでの特定のアクションを伴う圧力の類似点を見ることができます。

答えが少し遅れても、これが役立つことを願っています。

2
Ionic