SQL Serverによる毎日の計画の再作成

実稼働環境でこの問題が発生しています。

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

SQL Serverは、すべての（ほぼ100％）古い実行計画を削除し、毎日一晩中（午後11:00から8:00に）再作成しています。これは、「自動更新統計」が無効状態のときにも発生していました。過去2〜3週間、「自動更新統計」をオンにしました。しかし、それはまだ起こっています。

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

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

影響：

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

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

この問題は、ビジネスの朝に発生します。UI/ Webページがより集中的にアクセスされる場合です。

誰がこれを引き起こしているのか、この問題を解決する方法の手がかりを持っていますか？どんな助けでも大歓迎です。

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

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のパートナー。別のことMAXDOPは、インスタンスのオプションの変更です。それらのログも確認してください。彼らもplancacheをフラッシュする必要があります。

最後になりましたが、サーバーサイドトレースを実行することもできます（プロファイラーを使用して設定、起動、停止、sqlコマンドを使用してサーバーサイドで再度起動するだけです）。それの横にperfmonあなたの友人がいます。しばらくの間、パフォーマンス値を監視および監視できます。たぶん、あなたはそれらのフラッシュを引き起こすかもしれないあなたのサーバー上の特定のアクションで圧力の類似点を見ることができます。

答えが少し遅れて来たとしても、これがあなたの助けになることを願っています。