Discussion :

[dkmix]

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

[mikedavem]

Qu'appeles-tu HS ?

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

++

[dkmix]

Merci pour votre réponse.

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

[mikedavem]

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.

++

[SQLpro]

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 :

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

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

A +

[dkmix]

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 :

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

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

[SQLpro]

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 :

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

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 :

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

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

index_id étant l'id de l'idnex.

A +

[dkmix]

SQLPRo, merci pour le temps passé

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 :

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

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 :

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

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

[mikedavem]

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 ?

++

[dkmix]

Bonjour mikedavem

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