web-dev-qa-db-fra.com

Fragmentation de 100% d'index

Je frappe des problèmes de performance de la base de données, nous avons donc reconstruit tous nos index car nous n'avons pas fait un excellent travail en les conservant. Rebuild a couru pendant environ 20 minutes. Alors j'ai trouvé une requête pour voir comment mes index recherchent

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

Donc, la plupart de mes index ont une fragmentation en pourcentage moyenne <1 mais j'ai environ 10 à 85%, et 10 autres 100%

Je ne suis pas de DBA et je comprends très peu de ce que je fais ici, mais c'est sûrement très mauvais?

Il convient également de noter que les 100% sont toutes des clés primaires

Suis-je dans un monde de problèmes, ou ma compréhension des statistiques est-elle incorrecte?

remarque: la peine de mentionner ma base de données est de 24 Go et mon lecteur a 46 Go gratuit sur 115 Go

These are my worst indexes as per sql above

Modifier: Comme demandé Script Reindex ci-dessous

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

résultats de la fragmentation d'index d'origine Qry attachée comme demandé résultats

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

Oui La fragmentation aura une incidence négative sur la performance.
[.____] quelque chose de plus de 30% est mauvais, mais sur une petite table n'aurait toujours pas d'impact majeur.
[.____] mais sur une petite table de défragmentation est rapide alors pourrait aussi bien le faire.

Ce rapport que vous avez affiché est de 20 rangs et commence le 96. Vous pourriez également avoir> 30% sur certains grands index. En rangées 1-95, je peux plutôt vous garantir que vous avez des index de problèmes. Ceci est une base de données de 24 Go et vos indices d'État n'ont pas été maintenus. Ce que vous lisez n'est pas un problème mais où il y a de la fumée, il y a le feu.

Reconstruire tout est un peu beaucoup.
[.____] la guilde de Microsoft est

5% et <= 30% alter index se réorganisent
30% alter index reconstruisant avec (online = on) *

réorganiser et reconstruire index

Il y a des scripts là-bas qui iront et réorganiseront des versets de reconstruction par rapport à Skip.

Je ne suis pas d'accord avec Kin Ceci est une réponse au genou qui aura le moins d'aide. Oui, cela ressemble à des tables plus petites mais la défragmentation d'index est un bon point de départ pour examiner les problèmes de performance. Encore une fois, vous avez probablement de gros index fragmentés.

Vous pouvez ralentir la fragmentation en utilisant un facteur de remplissage <100. Mais votre index utilisera également plus d'espace. Sur une petite table, laissez-le seul.

Vous pouvez également ralentir la fragmentation en insérant des données dans l'ordre de l'index.

Après cela, regardez vos requêtes de préformation pire une à la fois et sur une performance d'adresses.

0
paparazzo