Votre code C# envoie donc une requête SQL ad hoc à SQL Server, en utilisant quelle méthode ? Avez-vous pensé à utiliser une procédure stockée ? Cela garantirait probablement les mêmes performances (au moins dans le moteur) quel que soit l'appelant.
Pourquoi? Le paramètre ARITHABORT est l'un des éléments que l'optimiseur examine lorsqu'il détermine comment exécuter votre requête (plus précisément, pour la correspondance de plan). Il est possible que le plan en cache ait le même paramètre que SSMS, il utilise donc le plan mis en cache, mais avec le paramètre opposé, votre code C # force une recompilation (ou peut-être que vous rencontrez un très MAUVAIS plan dans le cache), ce qui peut certainement nuire aux performances dans de nombreux cas.
Si vous appelez déjà une procédure stockée (vous n'avez pas posté votre requête, même si je pense que vous vouliez le faire), vous pouvez essayer d'ajouter OPTION (RECOMPILE) à la requête (ou aux requêtes) incriminée dans la procédure stockée. Cela signifie que ces instructions seront toujours recompilées, mais cela pourrait empêcher l'utilisation du mauvais plan que vous semblez utiliser. Une autre option consiste à s'assurer que lorsque la procédure stockée est compilée, le lot est exécuté avec SET ARITHABORT ON.
Enfin, vous semblez demander comment modifier le paramètre ARITHABORT dans SSMS. Je pense que ce que vous vouliez demander, c'est comment vous pouvez forcer le paramètre ARITHABORT dans votre code. Si vous décidez de continuer à envoyer du SQL ad hoc à partir de votre application C#, vous pouvez bien sûr envoyer une commande sous forme de texte contenant plusieurs instructions séparées par des points-virgules, par exemple :
SET ARITHABORT ON; SELECT ...
Pour plus d'informations sur les raisons de ce problème, consultez l'excellent article d'Erland Sommarskog :
- Lent dans l'application, rapide dans SSMS ? Comprendre les mystères des performances
