C'est ce que j'ai appris jusqu'à présent grâce à mes recherches.
.NET envoie des paramètres de connexion qui ne sont pas les mêmes que ceux que vous obtenez lorsque vous vous connectez à Management Studio. Voici ce que vous voyez si vous reniflez la connexion avec Sql Profiler :
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Je colle maintenant ces paramètres au-dessus de chaque requête que j'exécute lorsque je suis connecté au serveur sql, pour m'assurer que les paramètres sont les mêmes.
Dans ce cas, j'ai essayé chaque paramètre individuellement, après m'être déconnecté et reconnecté, et j'ai constaté que le fait de changer arithabort de off à on réduisait la requête du problème de 90 secondes à 1 seconde.
L'explication la plus probable est liée au reniflage des paramètres, qui est une technique utilisée par SQL Server pour choisir ce qu'il pense être le plan de requête le plus efficace. Lorsque vous modifiez l'un des paramètres de connexion, l'optimiseur de requête peut choisir un plan différent, et dans ce cas, il en a apparemment choisi un mauvais.
Mais je n'en suis pas totalement convaincu. J'ai essayé de comparer les plans de requête réels après avoir modifié ce paramètre et je n'ai pas encore vu le diff montrer les changements.
Y a-t-il autre chose dans le paramètre arithabort qui pourrait ralentir l'exécution d'une requête dans certains cas ?
La solution semblait simple :placez simplement set arithabort en haut de la procédure stockée. Mais cela pourrait conduire au problème inverse :modifiez les paramètres de la requête et tout à coup, elle s'exécute plus rapidement avec "off" qu'avec "on".
Pour le moment, j'exécute la procédure "avec recompilation" pour m'assurer que le plan est régénéré à chaque fois. C'est OK pour ce rapport particulier, car il faut peut-être une seconde pour recompiler, et ce n'est pas trop perceptible sur un rapport qui prend 1 à 10 secondes pour revenir (c'est un monstre).
Mais ce n'est pas une option pour les autres requêtes qui s'exécutent beaucoup plus fréquemment et doivent revenir le plus rapidement possible, en quelques millisecondes seulement.
