[MS SQL2005]Causes possibles d'un index HS

Bonjour,

J'ai un index non cluster sur 3 champs d'une table.
Cet index ne fonctionnait plus (HS) mais toujours présent.

J'ai fait un alter reorganize. aucun effet. L'index n'était pas fragmenté.
Je l'ai supprimé et recréer, et la il est redevenu OK.

Qu'est ce qui peut rendre HS un index ?

Merci

Qu'appeles-tu HS ?

Est-ce que cet index était désactivé ?

++

Merci pour votre réponse.

Citation:

---

Est-ce que cet index était désactivé ?

---

HS ou désactivé, effectivement, je n'ai pas pensé à vérifier si l'index était disable !!
Je ne vois pas pas pourquoi un traitement aurait déactivé cet index, et il n'y a pas eu de mise à niveau du moteur, mais c'est une possibilité...

Le symptôme était le suivant : temps de requête : 8 min, après réorganisation : 8 min, après re-création : 1 sec

Pour réactiver un index il faut de toute façon le reconstruire donc il y a des chances que ce soit cela mais bon sans réelle certitude :-) . Le problème est l'air d'être réglé de toute façon.

EDIT : Tu as parlé de réorganisation d'index dans le 1er post donc non on peut affirmer que l'index n'était pas désactivé à ce moment là à moins que tu aies eu un message d'erreur pendant cette opération. Il se peut maintenant que l'index était beaucoup trop fragmenté ou les statistiques associées n'étaient pas assez à jour pour que être utilisé par le moteur d'exécution. Le fait de reconstruire l'index supprime la fragmentation et met à jour les statistiques alors que la réorganisation d'index réduit partiellement la fragmentation en fonction de son taux mais ne met pas à jour les statistiques.

++

les index comme les tables se fragmentent. Les statistiques des index sont calculées lors d'une reconstruction, pas lors d'une défragmentation.
Si aucun plan de maintenance n'a prévu soit :

• la reconstruction
• le recalculs des statistiques

de manière régulière (au minimum une fois par mois, mais quotidien c'est encore mieux) alors l'optimiseur peut considérer cet index comme inutilisable pour établir son plan de requête car il ne peut se fier à des statistiques trop "vieilles".
Un peu comme si on établissait le budget de la nation avec la démographie des années 60 !!! - c'est pourquoi on fait de recensements....

Pour connaître la date du dernier calculs des stats, vous pouvez faire la requête :

Code:

---

1 2 3

SELECT OBJECT_NAME(object_id) AS table_name, *, STATS_DATE(object_id, stats_id) FROM sys.stats

---

A +

Bonjour, merci pour vos reponse,
Le probleme est revenu hier soir !!!

- l'index n'est pas desactivé.
-Il y a bien un plan de maintenance hebdomadaire qui reconstruit les index et met à jour les stats.

Avec la requete

Code:

---

1 2 3

SELECT OBJECT_NAME(object_id) AS table_name, *, STATS_DATE(object_id, stats_id) FROM sys.stats

---

Je vois que la date de mise à jour des stats pour cet index est 2012-07-03 12:06:30.640 soit la date à laquelle je l'ai reconstruit manuellement) et la précédente 2012-07-01 00:43:30.430 (soit la date du plan de maintenance)


Y'aurait-il des pistes d'analyse pour comprendre ce qui se passe ? avant que je le reconstruise

Vous dite "ne fonctionnait plus"
Moi je sais pas ce que ça veut dire.
Un index ne fonctionne pas.
Il peut être utilisé ou pas.
S'il n'est pas désactivé, il est toujours alimeté lors des mises à jour.

Vous pouvez voir le nombre des impacts DML de cet index avec :

Code:

---

1 2 3

SELECT * FROM sys.dm_db_index_usage_stats WHERE object_id = OBJECT_ID('$17')

---

Vous pouvez vérifier la santé de cet index avec :

Code:

---

1 2	DBCC CHECKTABLE ( '$17', index_id ) WITH ALL_ERRORMSGS

---

index_id étant l'id de l'idnex.

A +

SQLPRo, merci pour le temps passé

Citation:

---

Vous dite "ne fonctionnait plus"
Moi je sais pas ce que ça veut dire.
Un index ne fonctionne pas.
Il peut être utilisé ou pas.
S'il n'est pas désactivé, il est toujours alimeté lors des mises à jour.

---

Effectivement, je n'utilise surement pas les bons termes... :?

Je dirais donc, que j'ai une requete qui a lieu tous les soirs vers 23h00 et qui "devrait" utiliser cet index.
Ma requete est du genre :

Code:

---

1 2 3 4 5 6 7 8

WITH table_temp AS ( select ch1,ch2...,chN, ROW_NUMBER() OVER(ORDER BY [champsDeLIndexe1],[champsDeLIndexe2]) ) select .... FROM table_temp WHERE ROW_NUMBER BETWEEN 1 AND 1000

---

cette requete met 1 seconde en temps normale, mais lundi et hier, elle a mis 8 min !

...sinon j'ai repris l'analyse depuis le départ :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

/* index id */ select INDEXPROPERTY ( object_ID(maTable) , '$17' , 'IndexId') /* return 128 */   /* fragmentation index */ select avg_fragmentation_in_percent, page_count FROM sys.dm_db_index_physical_stats(DB_ID('maBD'), OBJECT_ID(maTable), NULL, NULL, NULL) WHERE index_id = 128 /* return ! après 1 min 30 ! */ avg_fragmentation_in_percent page_count 29,9687010954617 3834   /* check integrite table */ DBCC CHECKTABLE ( maTable, 128 ) WITH ALL_ERRORMSGS /* pas de message d'erreur */   /* stat utilisation index */ SELECT * FROM sys.dm_db_index_usage_stats WHERE object_id = OBJECT_ID(maTable) and index_id = 128 /* return : last user_seek : 2012-07-05 18:50:24.237 */ database_id object_id index_id user_seeks user_scans user_lookups user_updates last_user_seek last_user_scan last_user_lookup last_user_update system_seeks system_scans system_lookups system_updates last_system_seek last_system_scan last_system_lookup last_system_update 11 1177276195 128 1631 12 0 33521 2012-07-05 18:50:24.237 2012-07-06 10:15:01.853 NULL 2012-07-06 16:30:52.853 0 2 0 0 NULL 2012-07-05 08:43:11.210 NULL NULL

---

Si je comprends l'index a été utilisé à 18h50 pour la dernier fois ?
Il n'a donc pas été utilisé dans ma requête à 23h00

Pourquoi ne pas récupérer les plans d'exécution de la requête concerné via le profiler lorsque celle-ci s'exécute pour voir ce qui se passe quand elle met une seconde et quand elle met plusieurs minutes ?

++

Bonjour mikedavem

Citation:

---

Pourquoi ne pas récupérer les plans d'exécution de la requête concerné via le profiler

---

J'ai du reconstruire l'index pour mon traitement journalier de 23H. Si le problème se reproduit, j'irais voir dans l'analyseur de requête

A suivre