インデックスの再構築時間は断片化レベルに依存しますか？

インデックスの再構築に必要な時間は、断片化のレベルに依存していますか？

80％フラグメント化されたインデックスの再構築は、40％フラグメント化された同じインデックスの再構築に1分かかる場合、約2分かかりますか？

特定の状況でどのアクションが必要かについてではなく、必要なアクションを実行するために必要となる可能性があるRUNTIME（たとえば、秒単位）を求めています。インデックスの再編成または再構築/統計の更新を行う必要がある場合の基本的なベストプラクティスを知っています。

この質問では、REORGおよびREORGとREBUILDの違いについては尋ねられません。

背景：さまざまなインデックスメンテナンスジョブ（毎晩、週末は重いジョブ）のセットアップのため、毎日の「非常に負荷の高い」オフラインインデックスメンテナンスジョブは、中程度の断片化されたインデックスでより適切に実行して、オフタイムが小さい-またはそれは問題ではなく、80％フラグメント化されたインデックスでの再構築は、40％フラグメント化された同じインデックスでの同じ操作と同じオフタイムを取る可能性があります。

私は提案に従い、何が起こっているのかを自分で見つけようとしました。私の実験的なセットアップ：他にNOTHINGを実行し、他の誰にも使用されていないテストサーバーで、いくつかの追加の列と異なるデータ型[2つの数値、9つの日時、 2 varchar（1000）]と単純に行を追加しました。提示されたテストでは、約305,000行を追加しました。

次に、更新コマンドを使用して、整数値でフィルタリングする行の範囲をランダムに更新し、文字列値を変更してVarChar列の1つを変更し、断片化を作成しました。その後、で現在のavg_fragmentation_in_percentレベルを確認しましたsys.dm_db_index_physical_stats。ベンチマークに「新しい」断片化を作成するたびに、この値を含めてこの値を追加しました。これにphysical_page_countは、次の図を構成する記録が含まれています。

それから私は走りました：そして私の録音に使用することによってAlter index ... Rebuild with (online=on); つかみましCPU timeたSTATISTICS TIME ON。

私の期待：私は少なくとも、断片化レベルとCPU時間の間の依存関係を示す一種の線形曲線の兆候を見ることを期待していました。

これはそうではありません。この手順が良い結果に本当に適切かどうかはわかりません。行/ページの数が少なすぎるのではないですか？

しかし、結果は、私の元の質問に対する答えが間違いなくNOになることを示しています。SQL Serverがインデックスを再構築するために必要なCPU時間は、断片化レベルにも基になるインデックスのページ数にも依存していないようです。

最初のグラフは、以前の断片化レベルと比較した、インデックスの再構築に必要なCPU時間を示しています。ご覧のとおり、平均線は比較的一定であり、断片化と必要なCPU時間の間に観察可能な関係はまったくありません。

再構築に多少の時間を必要とする可能性がある、更新後のインデックス内のページ数の変化の影響を尊重するために、FRAGMENTATION LEVEL * PAGES COUNTを計算し、必要なCPU時間の関係を示す2番目のグラフでこの値を使用しました対断片化とページ数。

ご覧のとおり、これは、ページ数が変わっても、再構築に必要な時間がフラグメント化の影響を受けることを示していません。

これらのステートメントを作成した後、巨大で高度にフラグメント化されたインデックスを再構築するために必要なCPU時間は行の数によってのみ影響を受ける可能性があるため、手順が間違っていると思います。私はこの理論を本当に信じていません。

だから、私は本当にこれを絶対に知りたいので、それ以上のコメントや提案は大歓迎です。

断片化のレベルに応じて、インデックスの再構築に必要な時間はありますか？

これは、SQLサーバーが決定する主要なパラメータではなく、インデックスの再構築/再編成に時間がかかると思います。

「DATA」に基づいて関与するさまざまな他の要因があり、それを介して、どれだけの時間がかかるかを決定します。

要因1：テーブルのサイズ

要因2：可用性の懸念

要因3：パーティション化

要素4：インデックス列と一意性

これらの要素の詳細については、こちらを参照してください。

同じインデックスの40％の再構築に1分かかる場合、80％の断片化されたインデックスの再構築には約2分かかりますか

もう一度答えはそれが依存することができます！数値については、シナリオをテストし、それがどのように機能するかを確認する必要があります。FRAGレベル80の場合、再構築にX時間\分\秒かかり、フラグメントレベル40の場合、再構築にY時間\分\秒かかりました。履歴を計算して保持し、15日間（スケジュールされたメンテナンスアクティビティによって異なります）を言い、実際に両方を比較するのにどれだけ時間がかかるかについて結論を出すことができます。

さらに：

インデックスの再構築の進行状況に関するデータ\計算を収集できます：

DMV sys.dm_exec_requestsまたは

OlaのRe-indexing-Re-organizingのメンテナンスプランがある場合、SQL Serverインデックスと統計のメンテナンスで説明されているように、メンテナンス中に実行されたアクションの履歴をテーブルCommandLog内に保存するオプションがあります。データが保存されたら、コマンドタイプ「ALTER_INDEX--REBUILD」と、列の開始時間と終了時間の違いをクエリできます

興味のある方のために、私は、インデックスの断片化とページのサイズに関連して、数週間以内に約2500のインデックス再構築のインデックス再構築期間を示すグラフを作成しました。

このデータは、10のSQL Server、数百のテーブル、およびOla Hallengrenの最適化手順に基づいています。再構築の一般的なしきい値は5％の断片化に設定されています。

読みやすくするために、この統計で最大のテーブル（10 Mi +ページ）の一部を切り捨てました。

チャートは、泡のサイズとして必要な時間（期間）を示しています。最大のバブルの値は約220秒です。インデックスの再構築に必要な時間は、実際には断片化とは関係がないことを示しています。代わりに、インデックスのページ数により依存しているようです。また、低レベルのフラグメンテーションは、高レベルのフラグメンテーションよりも時間がかかることを示しています。

2番目のグラフは、200 Kページ以下の領域に拡大されています。同じように表示されますが、断片化が増えるのではなく、インデックスが大きいほど時間がかかります。

REBUILDインデックスはフラグメント化に依存しません。インデックスを完全に削除し、最初から作成します。

REORGANZE index-インデックスを再構築せずに断片化を減らすためのもので、ドロップや作成はありません。

MSは、30％以下の断片化にはReorganizeを使用することをお勧めします。より高い断片化には、再構築が推奨されます。

これに関するMSDNの記事は次のとおりです。インデックスの再編成と再構築

更新

操作の完了までにかかる時間に関しては、インデックスの断片化に明らかに依存します。非常に断片化されたインデックスの再構築は、再編成よりも時間がかかりません。わずかに断片化されたインデックスの再構築には、かなり時間がかかります。MSガイドラインを開始点として、テーブルでいくつかのテストを実行することをお勧めします。断片化％に関する損益分岐点は、特定のテーブル、インデックスのサイズ、およびデータのタイプによって異なります。

同じインデックスを40％フラグメント化した場合の再構築に1分かかる場合、80％にフラグメント化したインデックスの再構築には約2分かかりますか？

REBUILDとREORGのアルゴリズムは異なります。REORGは、REBUILDではなく新しいエクステントを割り当てません。REORGは現在割り当てられているページ（ページを移動できるように1つの8Kbランダムページを割り当てます）で動作し、必要に応じてページを移動して割り当てを解除します。

私のSQLSkills内部（以前はIE0）のメモから....

再構築の場合：

• 複数のCPUを使用できます-並列処理を利用して作業を高速化できます。
• 非常に断片化されたインデックス（例では80％）の場合、REBUILDはREORGよりもはるかに高速です。REBUILDはインデックスの別のコピーを作成するだけですが、REORGは断片化の削除に行き詰まるため、速度が低下します。これが、Paul Randalが、非常に断片化されたインデックスのREBUILDを実行するのが良いだろうという彼の一般的な推奨を与えた理由です。
• REBUILDを使用すると、生成するログレコードを少なくして、ログを最小限に抑えるために、リカバリモードをBULK_LOGGEDに変更できます。

インデックスREORGの場合：

• 常にシングルスレッドです。並列処理はありません。
• 断片化が激しいインデックスの場合は遅くなり、断片化が軽いインデックスの場合は速くなります。インデックスの作成と、断片化の軽いインデックスの再編成を行う場合のコストは大きくなるため、断片化の軽いインデックスの場合、REORGの方が高速になります。
• REORGは常に完全にログに記録された操作です。

続きを読む- メモ-SQL Serverインデックスの断片化、タイプ、およびソリューション

古いスレッドであることは知っていますが、Paul Randalの投稿をここで共有することは有益だと思います。

アルゴリズム速度

断片化がない場合でも、インデックスの再構築は常に新しいインデックスを構築します。再構築にかかる時間は、インデックス内の断片化の量ではなく、インデックスのサイズに関連しています。

https://www.sqlskills.com/blogs/paul/sqlskills-sql101-rebuild-vs-reorganize/

はい。通常、再構築では、行を（順番に）新しい物理インデックスパーティションにストリーミングしながら、元のインデックスを順番にスキャンする必要があります。断片化はキャッシュされていないスキャンに悪影響を与えるため、再構築にはさらに時間がかかります。

どれだけ長くかかるかは、フラグメンテーションと、CPUがプロセス全体にバインドする方法に依存します。行のシリアライズはCPUをかなり集中的に使用するため、まったく問題にならない場合があります。または、通常の1.5MB /秒のランダムIOレートを取得している可能性があり、これは高速再構築よりも簡単に5〜10倍遅くなります（スキーマとデータによって異なります）。前提条件に応じて、おそらく1倍から100倍のスローダウンが考えられます。

同じインデックスを40％フラグメント化した場合の再構築に1分かかる場合、80％にフラグメント化したインデックスの再構築には約2分かかりますか？

それは線形関係ではありません。断片化メトリックは、パーティションのスキャンにかかる時間の非常に大まかなプロキシです。