web-dev-qa-db-ja.com

SQL Server 2012でのインデックスの再構築/再編成中に考慮すべき要素

sys.dm_db_index_physical_stats dm関数によって返されたavg_fragmentation_in_percentに基づいてインデックスのインデックスの再編成/再構築を選択することに混乱を感じています。

Msdnさんのコメント：

enter image description here

また、avg_fragmentation_in_percent値は、インデックスに存在する論理断片化の割合（これは、インデックスのリーフページ内の順序が正しくないページの割合です）を示します。

Reorganize of indexは常にページの物理的な順序を修正します。したがって、avg_fragmentation_in_percentでも30％を超えているため、インデックスの再編成を検討できます。インデックスの断片化の割合が減少します。

以下の例をご覧ください

SELECT 
    database_id, object_id,
    avg_fragmentation_in_percent,
    avg_page_space_used_in_percent,
    page_count,
    avg_fragment_size_in_pages
FROM
    SYS.Dm_db_index_physical_stats (Db_id('BPIGTN_GAL_APP_TST'), Object_id('NM_PPA_PROJECTION_MASTER'), NULL, NULL, 'SAMPLED')

結果

 Database_id Object_id  avg_fragmentation_in_percent  avg_page_space_used_in_percent    page_count  avg_fragment_size_in_pages
    37       913490383        99.36                           60.15                      314           1.003

上記の例では、平均fragmentationの99％を確認できます。これは、インデックスがより論理的な断片化を持っていることを意味します（ページの並べ替えが多い）。

それで、上の画像で見たインデックスを再編成します。

詳しくは以下の例をご覧ください。

ALTER INDEX PK_NM_PPA_PROJECTION_MASTER_PROJECTION_DETAILS_SID_RS_CONTRACT_SID ON NM_PPA_PROJECTION_MASTER REORGANIZE
GO

SELECT database_id,
       object_id,
       avg_fragmentation_in_percent,
       avg_page_space_used_in_percent,
       page_count,
       avg_fragment_size_in_pages
FROM   SYS.Dm_db_index_physical_stats (Db_id('BPIGTN_GAL_APP_TST'), Object_id('NM_PPA_PROJECTION_MASTER'), NULL, NULL, 'SAMPLED')

結果

Database_id Object_id   avg_fragmentation_in_percent    avg_page_space_used_in_percent  page_count  avg_fragment_size_in_pages
37           913490383           4.18                                       98.91           191       9.55

上記では、インデックスがre-organizedであるため、再編成後はaverage_fragmentationが4 percentに削減され、使用されるスペースも60 percent to 98 percentから増加します。

MsdnがAvg_Fragmentation_in_percent値を提案して、インデックスのReorganize/Rebuildについて検討する必要があります。

しかし、Avg_Fragmentation_In_Percentの値は、論理的な断片化のみを示し、インデックスで使用されていない領域の量は示していません。

そのため、インデックスの再編成/再構築のどちらを選択するかについて少し混乱しています。

インデックスの再構築またはインデックスの再編成を選択するために、Avg_fragmentation_in_percentとAvg_page_space_used_in_percentの両方の値を検討できますか？

インデックスの再構築または再編成を選択する際に考慮すべき正確なパラメータを教えてください。

sql-serversql-server-2012index
7
Tharunkumar Reddy

他の答えとは異なる方向に進んで質問します。デフラグルーチンが何分または何時間も実行され、あらゆる種類のリソース（CPU、メモリ、ディスク、おそらくtempdb）を使用した後、どのように定量化しますかインデックスを最適化するための時間とサーバーリソースの消費を、そうすることで得られた改善と比較しますか？

これはあなたの質問の答えにはならないことを理解していますが、私はあなたが自分自身すべてをうまく動かし、サーバーがすべて問題以外について打ち負かすのではなく、あなたが何をしているのかを注意深く考えてほしいです。

インデックスの断片化に関して、SQL Serverユーザーには奇妙な執着があります（私もそう思っていました）。これは通常、15年前のMicrosoftからのアドバイスと、Q＆Aフォーラム（これも含まれています）での多くのヒステリックな応答に基づいています。

人々は、あなたが参照する数字（再編成するために5％、再構築するために30％）を永遠に信心深い熱狂で頭に打ちつけてきました。だから彼らはそれをし続けます。私もそれがあらゆる種類の問題を引き起こすのを見てきました。ブロッキングとデッドロック、 破損 、本番ワークロードの中断（長時間実行メンテナンス）、そして最悪の場合：DBCC CHECKDBなどのより重要なメンテナンスを除いたインデックスメンテナンスの実行。

インデックスの再構築が行う良いことの1つは 統計の更新 であり、これは（大幅に簡略化して）オプティマイザにはるかに優れた情報を提供します処理対象のデータについて、そして（ここでも大幅に簡略化して）不正な実行計画をキャッシュから追い出すことができます。

また、人々は、すべてのインデックスを再構築し、すべてのインデックスを再編成して、統計を更新するなど、メンテナンスプランで非生産的なことを行います。これはおそらくあなたではないことを理解しています。

再構築または再編成するための単なる断片化率よりも多くの考慮事項があります。

  • クエリでもこのインデックスを使用しますか？
  • 私は本当に50以上のGBインデックス（シングルスレッド、ew）を再編成してLOBコンパクト化しますか？
  • 私は再構築がオフラインであり、ブロッキングを引き起こす可能性があるStandard Editionを使用していますか？

背景については、 ブログ投稿はこちら をご覧ください。完全な開示;それは私が働いている会社ですが、私以外の人がそれについてたくさん書いています。インデックスの断片化が問題になるときについての投稿さえあります。

他のデータベースプラットフォーム は、長い間このトピックについてより良いアドバイスをしてきました。

[〜＃〜] edit [〜＃〜]：数百億年の間にインデックスの断片化が発生しないようにする最善の方法は重要です：すべてのデータをキャッシュしてくださいRAM内。

8
Erik Darling

使用するものを決定するのに役立つ可能性のあるいくつかの違いを次に示します

  • Rebuildは複数のCPUを使用できますが、Reorganizeは常にシングルスレッドです。
  • インデックス統計の更新を再構築しますが、再編成は行いません
  • 再編成は、再編成と比較して、断片化されたインデックスの方が高速です。
  • RebuildではFILLFACTORを設定できますが、Reorganizeではできません
  • インデックスの再構築を使用するときにBULK_Logged復旧モデルに切り替えることにより、トランザクションログの使用量を削減できます。
  • Reorganizeは常にオンラインであり、Rebuildはオンラインとオフラインのどちらかを選択できます（オンラインはエンタープライズのみの機能ですが、新しく再構築されたものをスワップインする間、小さなインデックスの停止が必要になります）
  • Rebuildは古いインデックスを削除する前に新しいインデックスを作成する必要があるため、一度に1ページで機能するReorganizeと比較してより多くのスペース（スペースインデックスの約1.2倍）が必要なので、必要な空きスペースは8KBのみです。
  • 再編成は途中で停止することができ、それまでに行われた作業を失うことはありません。再構築は途中で停止した場合、トランザクション全体をロールバックする必要があるためです。
  • RebuildはLOBデータを操作しませんが、ReorganizeはデフォルトでLOBデータを圧縮します

Avg_fragmentation_in_percentが関係している限り、その数をあまり重視しません。インデックスを再構築して断片化を解消したとしても、ストレージ上でページが互いに隣接していることをどのように確認しますか。一方、ページが半分しか使用されていない場合、その悪い原因は、ページをディスクに格納するのにそれほどコストがかからない可能性がありますが、メモリへの読み取り時に貴重なメモリを浪費します。それは無駄な記憶です。

4
jesijesi

再編成するか、再構築するか、または何もしないかを検討するときは、Avg_fragmentation_in_percentとAvg_page_space_used_in_percentの両方を検討するのが適切です。

Avg_fragmentation_in_percentが低い場合でも、Avg_page_space_used_in_percentが低いと再編成のメリットが得られます（IOが追加されていないページでキャッシュリソースが使用されるため））。

そして、「30％以上=再構築」のアドバイスは、「Avg_fragmentation_in_percent> 30％であり、定期的に再編成している場合」と読む方がよいでしょう。 、次に再構築 "。テストが示すように、Avg_fragmentation_in_percentが非常に高くても必要なのはそれだけなので、再編成していない場合は、最初にそれを試してください。

使用する正確なトリガーレベルについては、データとその使用方法、および投稿されたjesijesiのような他のさまざまな要因によって異なります。

3
T.H.

Avg_page_space_used_in_percent列は、RebuildとReorganizeのどちらを選択するか、およびインデックスを決定することに関するものです。

インデックスの再編成と再構築 によると、RebuildとReorganizeはどちらもインデックスのFILLFACTORを尊重し、それに応じてページを埋めようとします。

したがって、再構築または再編成の直後に、Avg_page_space_used_in_percentがインデックスのFILLFACTORをかなり閉じていることがわかります。

詳細については、次のリンクをご覧ください。

インデックスの再編成と再構築

sys.dm_db_index_physical_stats

2
Scott Hodgin