web-dev-qa-db-ja.com

統計の更新を使用してインデックスビルドを最適に管理する方法は？

これは私が読んだ内容のフォローアップです メンテナンスウィンドウ中にトランザクションログのバックアップを停止する理由はありますか？ sp_BlitzErikによって提案された回答にあります。

Ola Hallengrenのインデックス作成スクリプトを使用し、以下のように設定を指定しています。私はこれを週に1回エージェントジョブで実行します。

@Databases nvarchar(max),
@FragmentationLow nvarchar(max) = NULL,
@FragmentationMedium nvarchar(max) = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh nvarchar(max) = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 int = 5,
@FragmentationLevel2 int = 30,
@PageCountLevel int = 500,

インデックスの再構築の一環として、更新統計が自動的に実行されることは知っていますが、統計の更新を処理する必要があると思われるすべてのデータベースに対して、次のデータベースプロパティが設定されています。

Auto Create Statistics = True
Auto Update Statistics = True
Auto Update Statistics Asynchronously = True

ただし、これらの設定と定期的な統計の更新について、ここで一般的にベストプラクティスは何ですか？統計を毎晩更新する必要がありますか？統計を更新する必要があるかどうかを測定する方法がわからないため、これらのデータベースプロパティを設定しています。

Sp_BlitzErikの回答で、彼は「統計を定期的に更新したいのですが、次のコマンドで更新できます：」

次のコマンドを使用しますが、統計を定期的に更新するのは非常に一般的です。

EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES',
                          @FragmentationLow = NULL,
                          @FragmentationMedium = NULL,
                          @FragmentationHigh = NULL,
                          @UpdateStatistics = 'ALL',
                          @OnlyModifiedStatistics = 'Y',
                          @StatisticsSample = NULL,
                          @LogToTable = 'Y';
sql-serverstatisticsola-hallengrenindex-maintenance
2
Philip

Ola Hallengrenのインデックス作成スクリプトを使用し、以下のように設定を指定しています。私はこれを週に1回エージェントジョブで実行します。

実行しているコマンドを分解してみましょう。

@FragmentationLevel1 int = 5,
@FragmentationLevel2 int = 30,
@PageCountLevel int = 500,

週に一度でも、これはばかげて攻撃的です。 5/30％が古代のマイクロソフトのアドバイスによるものであることは知っていますが、それはまさに古代のことです。先に進む時が来ました。

500個の8KBページであるインデックスを最適化するために時間をかけています。これは4MBのテーブルです。ハードウェアで4MBのメモリへの読み取り、または4MBのテーブルのメモリへの保持に問題がある場合、答えはインデックスのメンテナンスではありません。だから私はこれを少なくとも5000までクランクアップします。

SAN、SSD、およびRAM> 4GBの量を収容できる非32ビットサーバーなどの最新のハードウェアには、2000年代初頭の回転するPlatterドライブと同じデータアクセスの問題がありません。

私たちはレコードプレーヤーとCDについて話している。

インデックスの再構築は非常にまれにしか発生せず、インデックスの問題を修正するか、設定を変更する場合にのみ発生します。これが重要です。30％の断片化は実際の問題ではありません。これは、DBAが指示されたために行うことであり、測定できるものです。

だからここにあなたへの私の質問があります：あなたのサーバーはインデックスのメンテナンスにどれくらいの時間とリソースを費やしますか、そしてそれはクエリによって消費される時間とリソースをどれだけ減らしますか？

それを測定できれば、好きなだけ再構築して再編成できます。

...しかし、統計の更新を処理する必要があると思われるすべてのデータベースに対して、次のデータベースプロパティが設定されています...

ちょっとちょっと。自動更新統計（非同期でも）は、テーブルデータの20％+ 500行（テーブルが> 500行であると想定）が変更されたときに発生します。 100万行のテーブルがある場合、それは20万行です。トレースフラグ2371を使用すると、そのしきい値を動的に下げることができますが、統計の自動更新ではデフォルトのサンプリングアルゴリズムが使用されるため、データが大きく偏っているテーブルには不十分な場合があります。

しかし、統計を定期的に更新することは非常に一般的です。

ええ、ええ、私は今まで見たことがないサーバーについての質問に答えています。私は毎晩の統計更新を好みますが、それよりも定期的に統計を必要とするサーバーを見てきました。

それで、あなたは何をすべきですか？

  1. 参照している質問に投稿したコマンドにインデックスのメンテナンスをダイヤルバックすることから始めます

    問題が発生した場合は、断片化のしきい値を停止するまで減らします。誰も何も言わない場合は、インデックスメンテナンスの実行頻度を減らしてください。おそらく、まったく実行しないまで実行してください。

  2. 毎晩統計を更新する

    デフォルトのしきい値から始めます。再構築で発生する完全な統計更新が必要であることがわかった場合は、CommandLogテーブルを使用して、定期的に再構築されているテーブルとインデックスを見つけ、それらに焦点を合わせ始めます。これらは通常、数千万行の「大きな」テーブルのインデックスになります。

これは、私が今まで見たことがないサーバーについて得ることができるのとほぼ同じくらい具体的です。ここから実験を行う必要があります。

私の投稿も参照してください ほとんどの人が自動更新統計をオンのままにしておく必要がある理由

3
Erik Darling