FORCE ORDER
Le
Jean-Nicolas BERGER
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.
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.
Poser une question
depusi quand vos index n'ont-il pas été défragmenté ? Quel sont les
dates de calculs des dernières statistiques ??
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
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...
Essayez des les reinitialiser avec un echantillon complet.
"Jean-Nicolas BERGER" <noreply> a écrit dans le message de
news:%
Je vais essayer de coupler ça à ma procédure de reconstruction des indexes,
et je vous tiens au courant.
Merci.
JN.
Et il faut reconstruire aussi les index non cluster .
inspirez vous de la procédure que j'ai mise en ligne (et qu'il faudrait
adapter pour 2005, mais elle marche quand même bien...)
http://sqlpro.developpez.com/optimi...anceIndex/
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************