sql >> データベース >  >> RDS >> Database

統計の自動更新の追跡

    SQL Serverで新しいデータベースを作成すると、[統計の自動更新]オプションがデフォルトで有効になります。通常、このオプションは有効のままにしておくことをお勧めします。理想的には、統計はスケジュールされたジョブによって管理され、自動オプションはセーフティネットとして使用されます。スケジュールされた更新が発生しない場合、または誤って既存の統計がすべて含まれていない場合に統計を更新するために使用できます。

    一部のDBAは、統計を管理するために自動更新のみに依存しており、古い統計または不十分にサンプリングされた統計に関連するパフォーマンスの問題が存在しない限り、これは許容されます。統計を管理するためにこのオプションに依存していて、非常に大きなテーブルがある場合は、トレースフラグ2371を実装する価値があるかもしれません。他のトレースフラグと同様に、実稼働環境に実装する前に、必ず代表的なワークロードでテストしてください。自動更新がシステムのパフォーマンスに影響を与える場合があることをすでにご存知かもしれません。たとえば、統計の更新により、テーブルまたはインデックスデータの読み取り時にCPUまたはI / Oが急増したり、更新が発生している間クエリの実行が遅れたりする可能性があります。そのクエリの遅延に対処するために有効にできる別のデータベースオプションがあります。これについては、この投稿の後半で説明します。

    私がよく聞かれる質問は、「統計の自動更新が原因であるかどうかをどうやって知るかです。 パフォーマンスの問題?」1つのオプションは、それらを追跡し、更新をパフォーマンスの変化に結び付けることです。更新を追跡するための多くのオプションがあります。この投稿では、使用可能な方法をいくつか確認して、選択して実装できるようにします。パフォーマンスの問題を監視する既存の方法に最適なオプション。

    SQLトレース

    ご使用の環境でSQLServer2008 R2以下を実行している場合、SQLトレースは自動更新をキャプチャするために使用できる1つの方法です。以下で使用されるトレース定義スクリプトは、統計が自動更新されたとき、および統計が自動作成されたときにキャッチするAutoStatsイベントのみをキャプチャします。このトレースが環境でしばらく実行された後、それをテーブルにロードし、出力をクエリして、どの更新が発生したかを確認できます。以下に含まれているスクリプトは、野球の統計サンプルデータベースを使用した例を示しています。

    拡張イベント

    SQL Server 2012以降を実行している場合は、拡張イベントを使用して自動更新をキャプチャすることをお勧めします。 SQLトレーススクリプトと同様に、含まれているセッション定義スクリプトは、自動統計イベントのみをキャプチャします。これも、自動更新と自動作成の両方です。 XEセッションがしばらく実行されたら、UIを介して出力をテーブルにロードし、クエリを実行して、発生した更新を確認できます。含まれているスクリプトは以前と同じ例を示していますが、今回は拡張イベントを使用してデータを収集しています。

    sys.dm_db_stats_properties

    統計の更新を監視するために検討できる3番目のオプションは、sys.dm_db_stats_propertiesです。 DMFは、SQL Server 2008 R2 SP2以降、およびSQL Server2012SP1以降でのみ使用できます。私がこのDMFを気に入っているのと同じように、このソリューションは、すべてのデータを確実にキャプチャするという点で扱いにくく、出力の確認にはより多くの作業が必要です。 DMFを使用すると、すべての自動更新が追跡されるわけではなく、統計の更新情報をトレンド分析して、更新がいつ発生するかを確認します。

    これは簡単な作業です。統計情報を保持するテーブルを作成し、DMFからテーブルに定期的に情報をスナップショットします。ここで重要なのは、データをキャプチャする頻度を把握することです。 1時間ごとはおそらくやり過ぎであり、1日1回は十分な頻度ではない可能性があります。 4時間ごとにDMFデータのスナップショットを作成するSQLエージェントジョブから始めることをお勧めします。それを数日間実行してから、データを確認してください。統計が最大で1日1回更新される場合は、間隔を8時間または12時間ごとに増やすことができます。統計が4時間ごとに簡単に更新される場合は、間隔を2時間ごとに減らします。つまり、各更新を確実にキャプチャする必要があります。このため、一部のシステムでは、sys.dm_db_stats_properties 努力する価値がないかもしれません。 XEセッションまたはトレースの方が簡単な場合があります。

    最後のサンプルスクリプトでは、sys.dm_db_stats_propertiesの使用方法の例を説明します。 統計の更新をトレンド分析します。このスクリプトは、1つのテーブルの統計情報のみをキャプチャすることに注意してください。データベース内のすべてのテーブルをキャプチャするようにスクリプトを変更すると、分析するデータがさらに多くなります。

    次のステップ

    サンプルスクリプトをダウンロードし、統計の更新を追跡するために使用する方法を決定します。

    自動更新がいつ発生するかを示すデータを取得したら、それを既知のパフォーマンスの問題に関連付ける必要があります。そのため、パフォーマンスメトリックを追跡していない場合、自動統計更新データはどのような種類の相関にも役立ちません。パフォーマンスの問題のタイムスタンプがあると仮定すると、それをStartTimeと比較できます。 およびEndTime トレースから、timestamp XEから、またはlast_updated sys.dm_db_stats_propertiesから DMF、自動更新がシステムパフォーマンスに影響を与えたかどうかを判断します。

    更新とパフォーマンスの問題の間に相関関係を作成できない場合は、問題の原因として更新を除外し、別の領域に焦点を当てることができます。更新が根本的な原因である場合は、2つのオプションがあります。[統計の自動更新]オプションを無効にするか、[統計の非同期の自動更新]オプションを有効にします。どちらにも、DBAとして考慮しなければならない長所と短所があります。

    自動更新統計の無効化

    統計の自動更新オプションを無効にすることを選択した場合、知っておくべき2つの最も重要なことは次のとおりです。

    1. メンテナンスタスクまたはカスタムジョブを介して統計を管理する必要があります。
    2. SQL Server 2008 R2以下で統計を更新すると、クエリは再コンパイルされません。

    私は2番目の項目をより大きな課題と見なしています。私は統計を管理することを大いに支持しており、DBAがとにかくやっていることを期待しています。より大きな問題は、統計を通常更新しているにもかかわらず (更新された統計を利用するために)クエリを再コンパイルしますが、これはしません 自動更新統計オプションを無効にしている場合に発生します。これについては以前に書いたので、この動作に慣れていない場合は、この情報を確認することをお勧めします。それに対処するためのオプションについては、フォローアップの投稿も参照してください。

    一般的に、これは私が推奨するパスではありません。これが適切である可能性のある非常に特殊なエッジケースがありますが、自動更新を回避するためにDBAが(スケジュールされたジョブを介して)手動更新を実行し、安全対策としてオプションを有効のままにしておくことをお勧めします。

    統計の自動更新を非同期的に有効にする

    Auto Update Statistics Asynchronouslyオプションを有効にすると、統計が無効になり、その統計を使用するクエリが実行された場合、統計はクエリが完了するまで更新されません。更新は非同期です。ここでの利点は、更新が実行されたクエリに影響を与えないことです。欠点は、クエリが既存のプランを使用することです。これは、もはや最適なプランではない可能性があります。計画がまだ最適であるかどうかは、ワークロード(たとえば、長時間実行されるクエリを使用したレポートワークロード)によって異なります。 DBAとして、このオプションを有効にすることの長所と短所を比較検討し、データベースに最適なものを決定する必要があります。 SQL Server 2008から2012を実行している場合、この設定に関連するメモリリークがあることに注意してください。 Microsoftには、修正を提供する累積的な更新プログラムがありますが、まだ適用していない場合は、別の決定に直面します。オプションを有効にできるようにCUを適用するか、CUを適用せずに有効にしないでください。オプション。

    概要

    統計の自動更新がクエリのパフォーマンスに影響を与えているかどうかを知る唯一の方法は、問題と同時に更新が発生するかどうかを確認するか、更新が発生したときにデータをキャプチャして、パフォーマンスの問題についてキャプチャする追加情報にデータを関連付けることです。後者のオプションを使用すると、プロアクティブになります。パフォーマンスの問題がない場合でも、自動更新が発生する頻度を知っておくとよいでしょう。頻繁に更新されるということは、統計を手動で管理するエージェントジョブに再度アクセスする必要があることを意味する場合があります。一般に、統計を自動的に更新するオプションは有効のままにしておきますが、統計を管理し、オプションをセーフティネットとして使用する方法があります。


    1. SQL同じテーブルのグループの列のSUMを更新する方法

    2. ClusterControl 1.7.2の発表:TimescaleDBとMySQL8.0のPostgreSQLバックアップとサポートの改善

    3. MySQLに保存された関数とプロシージャを作成して実行する方法

    4. ProxySQLをKubernetesサービスとして実行する