より広範な買収プロジェクトの一環として、SQL Serverのインスタンスを約20個継承しました。現在、パフォーマンスを評価中であり、メンテナンスプランの実装方法が気に入らない。
毎日のブランケットインデックスの再構築(これを処理できます)と、統計の毎日の手動更新が表示されています。
データベースの約半分は、統計の自動更新= Falseに設定されています。理由は、「パフォーマンスの問題」を減らすことだと言われていること以外は明確ではありません...
私は常にこれをTrueに設定するベストプラクティスを考えて取り組んできましたが、この設定がTrueの場合、手動更新は必要ないと感じました。私が間違っている?
誰もがこれをFalseに設定することの利点を説明できますが、代わりに毎日手動で更新することはできますか?
一部のデータベースはトランザクション性が高い(1日あたり数百万の挿入、削除、更新)ものもあります。その他のトランザクション率は低く、一部はすべて読み取り専用です。 Auto Update設定がFalseに設定されているのに、韻や理由はありません。宝くじのようです。
あなたは正しいです。また、ほとんどの場合、Auto Update statistics
をtrueに設定する必要があります。統計をいつ更新するかをSQL Serverが決定できるようにして、うまくいくと信じています。これがtrueに設定されている場合、オプティマイザがより良い計画を準備するのに最終的に役立つフィールドでのデータの分布に関する統計が確実に更新されます。ここで注意すべき重要な点は、テーブル内のデータの20%が変更されたときに統計を自動更新することです。したがって、10万行が更新された場合に10万行のテーブルでステータス更新が発生するとは感じないはずです。
より詳細な分析は、ブログのPaul Randalによって行われます 統計が自動的に更新されるタイミングを理解する 。このオプションがtrueに設定されている場合、欠点はありません。はい、このオプションをtrueに設定すると、一部のI/Oアクティビティを確認できます。
ブログから引き出せる重要な結論は
変更の結果として統計が古くなったとしても、変更の完了後に統計が自動的に更新されることはありません。統計は、クエリプランが次に統計を使用するときに自動的に更新されます。
読み取り操作のみのデータベース、または選択操作のみを行ってDML操作がないデータベースの場合、この場合、オプションをfalseに保つことができますが、trueを維持しても害はありません。ほとんどの場合、一定量のアクティビティーを持つデータベースが表示されます。
これはコメントには長すぎるので、統計の自動更新をオフにする必要がある別のケースについて説明します。私は大量のOLTPワークロードと厳しいクエリパフォーマンスSLAミリ秒単位)をサポートするデータベースを使用してきました。ほとんどすべてのクエリは、クエリとインデックスのチューニングの詳細、および一部のテーブルは非常に大きいものでした。この状況では、ピーク時に統計を更新してもあまり価値がなかったため、自動更新の統計はSLAに違反していました。スケジュールされたジョブ。
別のオプションは、両方をオンにすることですAUTO_UPDATE_STATISTICS
およびAUTO_UPDATE_STATISTICS_ASYNC
データベースオプション。これにより、統計を同期的に更新するオーバーヘッドが発生するのではなく、クエリが古い統計に基づいて実行プランを続行できるようになります。これは、OLTPワークロードの場合、サーバーがクエリワークロードとバックグラウンド統計の更新に対応できるサイズになっている限り、特に適しています。
一般に、統計の自動更新を有効にしておくと有益です。ただし、他の設定と同様に、オンまたはオフにできる理由があります。
1つは、いくつかのテーブルに多くのチャーンがあり、おそらくクエリは正確な統計にそれほど敏感ではないということです。 ETLまたは大量のデータを変更しているが、そこから読み取らない、またはあまり読み取らないその他の一括シナリオを考えてみてください。自動統計の更新を有効にして、大量のI/Oがこれまでにない正確な統計を提供するようにすることはあまり意味がありません。
また、1日に複数回データを更新するシナリオがありますが、更新のたびに統計を更新する必要はありません。 (たとえば、データのクエリは1日の特定の時間帯に限られます。とりあえずデータがクエリされない場合でも、統計を何度も更新する必要はありません。)
あるいは、書き込みが多いワークロードがあるだけかもしれません。または、読み取りは一般にフルスキャンであり、統計はそれほど重要ではありません。