クエリのパフォーマンス|統計の更新|オラハレングレンSP
私は最近、Tara Kizerがタイムアウトまたはクエリの実行が遅いときに開発者が彼女に近づくと言った何かを読んだり聞いたりしました。解決策は通常、統計を更新することでした。彼女はついに開発者と協力してコードを更新したことについて何か言い続けたと思いますが、記事やポッドキャストは見つかりません（それは彼女がキャリアの早い段階でIIRCについて話しているほどのものでした）。
とにかく、最近Ola Hallengrenのスクリプトをメンテナンスに使用するように切り替えた後、同じ問題が発生しています。私は新しい会社から始めて、メンテナンスプラン（毎週のインデックスの再構築）から、ジョブでOla Hallengrenのストアドプロシージャを使用するようにすべてを移行することに取り組んでいます（より頻繁に行う理由がない限り、毎週のインデックス/統計のメンテナンスを行っています）。これに使用している特定のコードは次のとおりです。
EXECUTE dbo.IndexOptimize
@Databases = 'ALL_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@LogToTable = 'Y'
奇妙なことに、これに切り替えた後、Taraが述べたとおり、開発者が私にアプローチしてきており、すべてのケースの修正は統計を更新しています（状況は4または5で、定期的に繰り返されています）。各ケースの詳細について説明せずに、なぜこれが突然表面化するのでしょうか？偶然の一致で、これまで問題を見たことはありませんでした。それは、Olaのスクリプトに切り替えた後にのみ発生しました。私はそれぞれのケースを掘り下げて、それらすべての後ろに悪いコードを見つけることができると確信していますが、全体として、2つの状況（MPとOlaのスクリプト）の違いは何でしょうか？メンテナンスプランは醜く、元に戻りたくありませんが、切り替え後の生産に問題がある場合、OlaのSPで仕事に行くことのビジネス価値を表現するのに苦労しています。
私は誰もがこれについて持っているどんな考えにも感謝します。
質問自体には具体的には回答していませんが、ここに記載されているようにトレースフラグ2371を設定することで、この問題を軽減することができました。
SQL Serverのバージョンに応じて、メンテナンスプランはインデックスの再編成または再構築all（2016年以降、特定の断片化レベルのインデックスのみを処理するようにしきい値を設定できると思います）。
したがって、Olaのスクリプトを使用すると、再構築するのに十分なほど断片化されていないインデックスがあります。 Olaのスクリプトを使用すると、（提供するパラメーターに応じて）すべての統計を更新できますが、ジョブは以前よりも速く完了する場合があります。したがって、統計が更新されている時点で、多くの変更を行う他のジョブが実行されず、統計の有効性が失われるほどの変更が発生する可能性があります。
（余談ですが、@OnlyModifiedStatistics = 'Y'を使用していたことに気付きました。実験として、これを'N'に変更するとどうなるかを確認できます。）
あるいは、（たとえば）検討するインデックスのセットを制限した場合、Olaのスクリプトは更新される統計に同じ制限を課します。
T-SQLまたはメンテナンスプランを使用して、統計を更新するジョブを設定できます。これは、再構築ジョブよりも頻繁に実行できます。
更新：私は当初、Olaのスクリプトが再構築/再編成したインデックスの統計のみを更新すると想定していました。そうではありません。コメントに追加した情報を引き出しました。
提案は同じです。統計を更新するための別のジョブを用意し、そのジョブを週の間に実行し（必要に応じて、ジョブに時間がかかりすぎない場合は毎日）、苦情が減るはずです。