web-dev-qa-db-ja.com

100％インデックスの断片化

データベースのパフォーマンスの問題が発生しているため、インデックスを維持するための優れた作業を行っていないため、すべてのインデックスを再構築しました。再構築は約20分間実行されました。次に、インデックスがどのように見えるかを確認するクエリを見つけました

SELECT 
t.NAME 'Table name',
i.NAME 'Index name',
ips.index_type_desc,
ips.alloc_unit_type_desc,
ips.index_depth,
ips.index_level,
ips.avg_fragmentation_in_percent,
ips.fragment_count,
ips.avg_fragment_size_in_pages,
ips.page_count,
ips.avg_page_space_used_in_percent,
ips.record_count,
ips.ghost_record_count,
ips.Version_ghost_record_count,
ips.min_record_size_in_bytes,
ips.max_record_size_in_bytes,
ips.avg_record_size_in_bytes,
ips.forwarded_record_count
FROM 
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN  
sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
AVG_FRAGMENTATION_IN_PERCENT > 0.0
ORDER BY
AVG_FRAGMENTATION_IN_PERCENT, fragment_count

したがって、ほとんどのインデックスの平均断片化率は1未満ですが、約10が85％、さらに10が100％です。

私はdbaではありません、そして私がここで何をしているのかほとんど理解していませんが、確かにこれは非常に悪いですか？

また、100％はすべて主キーであることにも注意してください。

私は問題の世界にいますか、それとも統計の理解が間違っていますか？

注：私のデータベースは24 GBで、ドライブには115 GBのうち46 GBの空き容量があることに言及する価値があります。

These are my worst indexes as per sql above

編集：要求された以下の再インデックススクリプト

DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE @fillfactor INT
SET @fillfactor = 80
DECLARE TableCursor CURSOR FOR
SELECT OBJECT_SCHEMA_NAME([object_id])+'.['+name+']' AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
print @TableName
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD WITH (FILLFACTOR =     ' + CONVERT(VARCHAR(3),@fillfactor) + ')'
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO

要求通りに添付された元のインデックスフラグメンテーションqryの結果 results

sql-serverindexsql-server-2014index-tuning
3
Crudler

データベースのパフォーマンスの問題が発生しているため、インデックスを維持するための優れた作業を行っていないため、すべてのインデックスを再構築しました。

これは、パフォーマンスの問題に対する knee-jerk 応答です。 ページ数が10未満です！インデックスを再構築することは、あなたの場合にはほとんど役に立ちません。

SQL Serverのパフォーマンスを分析する方法を教えてください

7
Kin Shah

はい、断片化はパフォーマンスに悪影響を及ぼします。
30％を超えるものはすべて不良ですが、小さなテーブルでも大きな影響はありません。
しかし、小さなテーブルではデフラグは高速なので、そうすることもできます。

投稿したレポートは20行程度で、96から始まります。一部の大きなインデックスで30％を超える場合もあります。 1〜95行目では、問題のあるインデックスがあることをほぼ保証できます。これは24 GBのデータベースであり、インデックスは維持されていません。あなたがリストしたものは問題ではありませんが、煙があるところには火があります。

すべてをリビルドするのは少し大変です。
Microsoftのギルドラインは

5％および<= 30％ALTER INDEX REORGANIZE
30％ALTER INDEX REBUILD WITH（ONLINE = ON）*

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

そこに行き、再構築対スキップの詩を再編成するスクリプトがあります。

私はキンに同意しません。これは最低限の助けになる膝の反応です。はい、それはいくつかの小さなテーブルのように見えますが、インデックスの最適化はパフォーマンスの問題を調べるための良い出発点です。繰り返しますが、断片化されている大きなインデックスがいくつかある可能性があります。

100未満のFILL FACTORを使用すると、断片化を遅くすることができます。ただし、インデックスはより多くのスペースを使用します。小さなテーブルでは、そのままにしておきます。

インデックスの順にデータを挿入することで、断片化を遅くすることもできます。

その後、より悪い実行クエリを1つずつ見て、パフォーマンスに対処します。

0
paparazzo