FORCE ORDER

Bonjour,
Sous SQL Server 2005 SP2, il m'arrive de temps en temps (encore une fois
hier) de tomber sur une instruction SELECT pas trop complexe (4 à 5
jointures INNER JOIN) avec des tables moyennement volumineuses (de quelques
milliers d'enreg à 1 ou 2 millions) qui se met à prendre 30 secondes voire
plus en durée d'exécution.
Après analyse, l'ordre des jointures ne me parait pas incorrect et, en
dernier ressort, je positionne un OPTION (FORCE ORDER), et là, miracle, la
durée retombe en dessous de la seconde !
Quelqu'un saurait-il me dire pourquoi un simple FORCE ORDER semble
nécessaire pour que la détermination du plan d'exécution ne parte pas en
vrille ?
Merci d'avance pour vos retours d'expérience.
JN.

>>

depusi quand vos index n'ont-il pas été défragmenté ? Quel sont les dates
de calculs des dernières statistiques ??

depusi quand vos index n'ont-il pas été défragmenté ? Quel sont les dates
de calculs des dernières statistiques ??

Bonjour Fred,

Le calcul des statistiques est automatique (et assynchrone).
Et pour ce qui est des indexes et de leur fragmentation, j'ai un REBUILD
des CLUSTERED au moins une fois par jour. Et dans le cas d'espèce de ce
test, j'ai essayé de forcer une reconstruction des indexes sans que cela
ne change grand chose aux performances.

Le plus étonnant est en fait que l'optimiseur parte en vrille et que le
fait de le brider avec le FORCE ORDER améliore les performances avec un
ratio d'au moins 100.!!!

JN.

PS : Petite correction : je ne suis pas en SP2 mais en Cumulative patch 6
(post SP2). Mais ces symptômes avaient de mémoire déjà été observés à
l'époque où nous étions en SP1...

> La remise a jour automatique des statistiques peut ne pas être suffisante.
Essayez des les reinitialiser avec un echantillon complet.

La remise a jour automatique des statistiques peut ne pas être suffisante.
Essayez des les reinitialiser avec un echantillon complet.

Je vais essayer de coupler ça à ma procédure de reconstruction des indexes,
et je vous tiens au courant.
Merci.
JN.