特定のデータベース内の更新統計に時間がかかりすぎる場合は、自動生成された統計を削除することを検討できますか? UPDATE STATISTICS WITH RESAMPLE
を使用して毎週メンテナンスを行っていますが、多くの場合、スクリプトが営業時間内に実行されなくなったため、スクリプトを停止する必要があります。
RESAMPLE
とFULLSCAN
を使用するのに最適なのはいつですか?
特定のデータベース内の更新統計に時間がかかりすぎる場合は、自動生成された統計を削除することを検討できますか?
自動作成されたすべての統計の削除
理論的には、自動生成された統計をすべて削除できます。これにより、クエリがオブジェクトの統計を必要とするときに再作成されるため、システムに一時的な負荷がかかります。
データベースで自動統計作成がオンになっている限り
さらに詳しい情報とこれらの統計を削除するスクリプトに興味がある場合は、Amy Levinの this blog にアクセスしてください。
重複統計の削除
重複した統計が存在する可能性があります。
この例は、自動作成された統計が列で作成された後に追加されるインデックスが原因です。これらをドロップしても問題はありませんが、いつものように再確認してください。
さらに詳しく、ShaunJStuart here によってこれらの重複統計を削除する方法。
スクリプトは、インデックスによって作成された統計と同じである自動作成された統計のみをドロップします
UPDATE STATISTICS WITH RESAMPLEを使用して毎週のメンテナンスを行っていますが、営業時間に達するとスクリプトを停止しなければならないことがよくあります。
更新統計の影響
UPDATE STATISTICS
は多くのCPUを使用し、IOは、統計情報があるテーブルと列のサイズに応じて異なりますが、ブロックしていません。
理論的には、使用するリソースの増加がクエリに影響を与えない場合は、本番稼働時間中に実行できます。
ブロックされていなくても、営業時間外に実行することをお勧めします(またはハードウェア/ワークロードの制限のために選択肢がありません)。これで最後の要点に戻ります。
RESAMPLEとFULLSCANを使用するのに最適なのはいつですか?
FULLSCAN <> RESAMPLE
Microsoft docs から定義をリサンプル
リサンプル
最新のサンプルレートを使用して各統計を更新します。
つまり、以前の更新がFULLSCAN
だった場合、RESAMPLE
もフルスキャンされます。
FULLSCAN
は、名前が示すように、テーブル/インデックス付きビューのすべての行をスキャンして統計を更新します。ここで、RESAMPLE
は前のサンプルレートを再利用します。
それらは異なりますが、同じUPDATE STATISTICS
ステートメントを実行できる場合があります。
次の3つの(簡略化された)シナリオを見てください。
FULLSCAN
を使用して統計を更新する例が機能しない
統計情報の自動更新が1時間おきに、または変更のために毎日トリガーされると、フルスキャンが実行されなくなります。これの別の結果は、ランダムな時間での計画の回帰です。
fullscan
を使用してテーブルの統計を更新していて、1時間後にそれらがすでに「自動更新」されている場合、これには長期的な影響はありませんでした。
FULLSCANが機能する場合
特定のテーブルの統計のフルスキャンを1週間近くまたは全体にわたって維持できる場合は、fullscan
がこれらのテーブルのオプションになる可能性があります。
これらのテーブルで毎週のフルスキャン統計の更新を行う場合。
フルスキャン更新の結果
fullscan
を使用して更新する場合、クエリのプランがランダムに異なるためパフォーマンスが低下する可能性があるため、統計の自動更新が敵になる可能性があります。
[〜#〜] resample [〜#〜]
RESAMPLEは、以前に使用されたstat更新を使用する必要がある特定の場合にのみ使用されます。ほとんどの実際のシナリオでは、これは不要であり、これを行うと予期しないことが発生する可能性があります。
統計の更新を高速化するには、FULLSCAN
なしで、またはSAMPLE RATE
付きで実行することを検討してください。
最初にできること
あなたは始めることができます:
重複した自動作成統計の削除
FULLSCAN
なしで統計を更新する(プレーンUPDATE STATISTICS
およびSQL Serverにサンプルレートを決定させる)
または
FULLSCAN
よりも低いサンプルレートを決定します。これは、SQL Serverによって決定されたサンプルレートよりも依然として大きくなります。低いサンプルレートの例は、10 PERCENTのサンプルレートです。
UPDATE STATISTICS ... WITH SAMPLE 10 PERCENT
つまり、テーブル/インデックス付きビューの行の10%がスキャンされ、統計が更新されます。
FULLSCAN
でさえSAMPLE RATE
より速いという転換点があるので、サンプルレートを高くしすぎないように注意する必要があります。
詳細はこちら 。
また、更新する必要がある統計と更新しない統計を確認する必要があります。営業時間外のこれらの統計に注目してください。
明示的な理由がない限り、RESAMPLE
には触れません。
追加の考慮事項
Ola Hallengrenのインデックスと統計のメンテナンス を使用すると、これにかかる時間を短縮できます。
変更された統計のみを更新するには、OnlyModifiedStatistics = 'Y'
を設定します。
StatisticsSample = 10
でサンプルレートを変更します
@ ErikDarlingが言及:
Olaは、StatisticsModificationLevelを追加して、どの統計を変更するかを制御します
これを実装する例としては、パラメータ@StatisticsModificationLevel = 5
を追加して、行の5パーセントが変更されたときにのみ統計を更新します。
これは動的なしきい値であり、変更された行の量に応じて5%より速く行を更新できることを覚えておいてください。この式は次のとおりです。
SQRT(number of rows * 1000)
この動的しきい値がolaのスクリプトのごく一部でどのように使用されているかを確認できます。
OR (@StatisticsModificationLevel IS NOT NULL
AND @CurrentModificationCounter > 0
AND (@CurrentModificationCounter >= SQRT(@CurrentRowCount * 1000))
これを説明する小さな例(インデックスのみに基づく)は、次のクエリを使用することでできます。
SELECT rowcnt as CurrentRowCount ,
rowmodctr as CurrentModificationCounter,
SQRT(rowcnt * 1000) as sqrtRowCount
FROM sys.sysindexes;
以下の結果セットで:
CurrentRowCount CurrentModificationCounter sqrtRowCount
2342 262 1530,3594349041
1118 490 1057,3551910309
16000 15000 4000
これらの3つのインデックスについて決定を下す動的しきい値に達すると、3番目のインデックスによって作成された統計のみが更新されます。