web-dev-qa-db-ja.com

テーブルの断片化

次を実行すると：

SELECT dbschemas.[name] as 'Schema', 
dbtables.[name] as 'Table', 
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent as avg,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID('dbname'), 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('dbname')
ORDER BY indexstats.avg_fragmentation_in_percent desc

断片化レベルを示します。次に、Ola Hallengrenのインデックス最適化スクリプトを実行して、明らかにインデックスを削減しました。

もう一度クエリを実行すると、インデックスのないテーブルに高い断片化が表示されます。例：

Schema  Table       Index   alloc_unit_type_desc   avg                 page_cont
dbo     tablename   NULL    IN_ROW_DATA            99.4362934362934    8176

これらについて心配する必要がありますか？

私にできることは？

私がやるべきことは何ですか？

パフォーマンスの問題が発生しています。 2008年は理想的ではないことを認識しています。

データファイルも220GBと表示されていますが、実際に使用されているスペースは140GBです。

sql-serversql-server-2008ola-hallengrenfragmentation
2
Round

Ola Hallengrenのインデックス最適化スクリプトは、ヒープの最適化を実行しません。

言い換えると、プロシージャの実行時にテーブルの再構築が行われず、それが予想されます。

ALTER TABLE dbo.tablename REBUILD;フラグメンテーションを削除します。

これにより、ヒープ上の非クラスター化インデックスも再構築されます。

ヒープテーブルを再構築するよりも優れたオプション

クラスタ化インデックスをテーブルに追加できない理由を自分またはアプリケーションチームに確認する必要があります。ヒープの再構築は多くのリソースを使用するため、一時的な解決策です。

クラスタ化インデックスを追加すると、そのインデックスはインデックス最適化スクリプトに含まれ、スクリプトの実行時に断片化が削除されます。

別のオプションは、クラスター化インデックスを追加することです インデックスの断片化の心配をやめます。

パフォーマンスの問題が発生しています。 2008年は理想的ではないことを認識しています。

それは、ヒープテーブルの転送されたレコードが原因である可能性がありますが、8167ページでは、その可能性は低いと言えます。まず、サーバーで実行されているクエリを確認することから始めます。

SP_BlitzCache は、パフォーマンスが最も低いクエリを見つけるのに役立ちます。

データファイルも220GBと表示されていますが、実際に使用されているスペースは140GBです。

これは問題にはなりません。ディスク容量は別として、あまり心配する必要はありません。良いことですが、自動成長に依存していません。

7
Randi Vertongen