Discussion :

[mic.gil]

Bonjour,

J'ai le problème suivant :

Sur un serveur SQL2005, comportant environ 20 bases de données, j'exécute une requête et les temps de réponse de la requête sont très différents (10s vs plusieurs minutes) suivant le contexte dans lequel je me situe(USE nomdedb),

Les chemin d'accès sont différents : Hash Match (réponse 7s) et Inner Join (réponse plusieurs minutes).

Le contexte posant problème est celui qui héberge les tables de la requête.

Merci pour votre aide

[aieeeuuuuu]

Bonjour,

S'agit-ils exactement de la même requête ? (est-ce que vous nommez vos noms de table en trois ou quatre partie, c'est à dire avec le nom de la base ?)

En lançant dans des contextes différents, vous générez à chaque fois une nouvelle compilation d'un plan d'éxécution. Vous pouvez (et visiblement c'est le cas) avoir deux plans différents.

Êtes-vous sur un serveur de test ? Si c'est le cas, vous pouvez ajouter OPTION(RECOMPILE) à la fin de la requête afin de forcer une recompilation de la requête et voir si le résultat est meilleur.

[mic.gil]

Merci beaucoup pour votre réponse : Le paramètre OPTION(RECOMPILE) résout bien le problème de cette requête.

Mais je ne peux modifier ces requêtes en environnement de Production.

Ainsi, comment puis je faire pour être sûr d'utiliser les meilleurs chemins d'accès, notamment en cas de modifications (ajout d'index dans mon exemple)? un DBCC FREEPROCCAHE régulièrement ? un arrêt/relance du serveur réinitialise t il tout? Autres?

(En réponse à vos questions : les noms de tables sont préfixés par le nom de la DB et les requêtes sont vraiment identiques (copie/coller dans le gestionnaire de requête)).

Merci

[mic.gil]

Bonjour,

en comparant le paramétrage des bases, j'ai vu une différence dans le paramètre 'PARAMETERIZATION '

Dans le contexte DB où j'ai PARAMETERIZATION SIMPLE, le chemin d'accès est bon.
Dans le contexte DB où j'ai PARAMETERIZATION FORCED, le chemin d’accès est défaillant.

J'ai modifié ce paramètre (ALTER DATABASE BINFP SET PARAMETERIZATION SIMPLE) et, effectivement, la requête s'est déroulée instantanément.

Il ne me reste plus qu'à analyser l'impact de ce paramètre (impact que j'espère négatif) pour le reste des requêtes sur cette DB.

Merci beaucoup pour votre aide

[mikedavem]

Hello,

L'avantage de cette option est de forcer SQL Server à "paramétriser" les plans d'exécutions pour qu'ils puissent être ultérieurement réutilisés mais cela peut également devenir un problème si le plan d'exécution généré n'est optimisé que pour un sous ensemble de valeurs de paramètres correspondants (SQL Server sniffe les valeurs de paramètres pour compiler le plan d'exécution).

Le fait de supprimer cette option de base de données peut améliorer ta requête mais peut aussi avoir un effet négatif comme tu le cites sur les autres requêtes et sur la taille du cache dédié à cela (compiled plan / adhoc).

++

[aieeeuuuuu]

Il y a aussi d'autre options.
Par exemple
- Il est envisageable de laisser le hint OPTION (RECOMPILE) pour cette requête spécifiquement, surtout si son cout de compilation est faible...
- En fonction de la façon dont la requête est/sera appelée, il est aussi possible d'utiliser OPTIMZE FORliste non exhaustive !

Est-il possible de voir la requête en question ?
Et un peu de détail sur le contexte, la volumétrie, ...