Discussion :

[Griswold]

Bonjour à tous,

Tout d'abord désolé si la question a déjà été posée et répondue, j'ai cherché sur le forum et je n'ai pas trouvé la réponse qui convenait.

Chez un client nous éprouvons des lenteurs incroyables dans des requêtes sur une table. Lorsque l'on exécute un DBCC Reindex le tout revient à la normale, mais le lendemain matin les lenteurs reviennent, nous devons exécuter la commande de nouveau.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC sp_msForEachTable @COMMAND1= 'DBCC DBREINDEX ( "?")'

À priori nous avons remarqué que pour un champ donné dans la table il existe deux index sur le dit champ. Dans la version précédente de notre logiciel nous n'avions pas les problèmes de lenteur, et seulement un index était présent.

Ma question étant, est-ce deux index sur un même champ peut faire en sorte de créer un tel genre de problème de performance?

Le premier index est sur une colonne mais avec une clause "include" contenant plusieurs autres colonnes. Alors que le deuxième index (qui était absent autrefois) est sur la colonne uniquement, sans clause "include".

Merci d'avance de l'aide que vous pourrez m'apporter.

[elsuket]

Bonjour,

Je vois que vous utilisez la clause INCLUDE, donc c'est que vous êtes au moins sous SQL Server 2005, ce qui signifie que vous pouvez utiliser l'instruction ALTER INDEX monIndex REBUILD.
Elle permet en outre de reconstruire l'index "en ligne", avec l'option WITH (ONLINE= ON).

À priori nous avons remarqué que pour un champ donné dans la table il existe deux index sur le dit champ

Cela n'est pas bon et c'est très probablement à l'origine de votre problème de performances, puisque pour toute nouvelle valeur insérée ou modifiée, vous devez mettre à jour également ces deux indexes.

Le premier index est sur une colonne mais avec une clause "include" contenant plusieurs autres colonnes. Alors que le deuxième index (qui était absent autrefois) est sur la colonne uniquement, sans clause "include".

Donc vous pouvez le supprimer, il est inutile.
Vous pouvez le voir à l'aide de la vue de gestion dynamique sys.dm_db_index_usage_stats.

Les lenteurs peuvent aussi être dues à taux de fragmentation de votre index, si votre table est très souvent modifiée (INSERT / UPDATE / DELETE).
Si elle est massivement insérée, utilisez le paramètre FILLFACTOR à la prochaine reconstruction de votre index.

Malheureusement sans la structure de la table, ses index, et une requête type sujette à lenteurs, je ne peux pas aller plus loin.

@++

[Griswold]

Merci beaucoup pour ton feedback!

Je vais valider avec les conseils que tu m'as donné, je te reviens dès que possible.

Merci encore!

[SQLpro]

Il y a probablement une fragmentation importante de cet index. Quelles sont les opérations DML faites en une journée ? Ne pouvez vous mettre un FILL FACTOR important ???

A +