web-dev-qa-db-ja.com

ヒープの断片化レベル

私は現在、Ola Hallengren氏から提供されたスクリプトを使用してメンテナンスジョブを実行しています。その後、テーブル（ヒープ）の断片化レベルが驚くほど高く、調査して対処する必要があることに気付きました。私はサイトで [〜＃〜] faq [〜＃〜] を確認しましたが、彼のスクリプトはヒープの再構築をサポートしていないようです。以下のクエリを使用して、断片化レベルを見つけました。

SELECT dbschemas.[name] as 'Schema', 
dbtables.[name] as 'Table', 
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID() and dbindexes.name is null
ORDER BY page_count desc, indexstats.avg_fragmentation_in_percent desc

私のアプリケーションはベンダーによってサポートされており、これらのヒープをテーブルに変更してクラスター化インデックスを作成するためにベンダーと通信していますが、意味のある結果は得られていませんただし、主キーは一意の非クラスター化インデックスとして定義されており、外部キーの一部でもあるため、変更を行う前に多くのレベルで変更する必要があります。まず、クラスタ化インデックスと一意のインデックスを持つ主キーの違い 説明 になるまでに何日もかかりました。

また、インデックスの最適化のためにOla Hallengren氏から提供されたスクリプトのデフォルトを変更して、より効率的にするためにBrent Ozar氏から提案された tweaks についても調べましたが、詳細はわかりませんでしたヒープの再構築。

私の理解によると、ヒープの断片化は、説明されているように2つの方法で処理できます here ：

  1. テーブルにクラスター化インデックスを作成して削除するには-これはすべての断片化をクリアし、すべての非クラスター化インデックスを再構築しますが、時間とI/Oを消費します。
  2. ヒープの再構築-これにより、断片化が解消され、テーブルの再構築の非クラスター化インデックス部分がすべて再構築されます。

クラスタ化インデックスを作成できる列を認識していないため、オプション1に進むことができません。また、オプション2よりも時間がかかる可能性があります。

Ola Hallengrenがスクリプトでオプション1を実装する可能性、またはこれを処理する別の方法を探しています。さらに、ヒープのサイズが10,000ページを超え、断片化レベルが80を超える場合にのみ、ヒープを再構築したいと思います。

Microsoft SQL Server 2014 SP3 Enterprise Editionを使用しています。

DBAとして-私はデータベースにヒープを持つことを好みませんが、これはベンダーがサポートするアプリケーションであり、主キーが一意のインデックスとして既に定義されており、これらのキーが外部キーであるため、それらをクラスターに変更することは非常に困難です。参照およびダウンタイムの可能性。

編集：Erik Darling氏から提供された link を確認したところ、転送されたレコードまたはデータベース間で削除されたヒープが多数あることを確認できました。今、私は私が始めたところから、つまりこれらの2つのオプションを使用して、ポイントに戻ります。前に述べたように、クラスター化インデックスの作成は私のシナリオでは非常に困難であり、複雑な外部キー構造を考慮すると、ダウンタイムが発生する可能性が高く、少なくとも数か月（楽観的）が必要です。ヒープの再構築と起こり得る副作用についてアドバイスが必要です。

sql-serversql-server-2014ola-hallengrenfragmentationheap
2
Learning_DBAdmin

ヒープには、クラスター化インデックスでは体験できないいくつかの特別な課題があります。

  • 転送されたレコード
  • キャプティブページ

データベースに対して sp_BlitzIndex を実行して、これらのいずれかがヒープで発生しているかどうかを確認することをお勧めします。そうでない場合は、そのままにしておきます。もしそうなら、あなたはそれらを再構築することを考慮する必要があるかもしれません。

現時点では、ヒープテーブルを再編成することはできません。ヒープテーブルを再構築すると、その上にある非クラスター化インデックスも再構築されます。それらを削除し、ヒープテーブルを再構築してから、非クラスター化インデックスを後で再作成する方が安上がりです。

あなたはここでこれについてもっと読むことができます：

9
Erik Darling