Entonces, su código C# está enviando una consulta SQL ad hoc a SQL Server, ¿usando qué método? ¿Ha considerado usar un procedimiento almacenado? Eso probablemente garantizaría el mismo rendimiento (al menos en el motor) independientemente de quién lo haya llamado.
¿Por qué? La configuración de ARITHABORT es una de las cosas que el optimizador observa cuando determina cómo ejecutar su consulta (más específicamente, para la coincidencia de planes). Es posible que el plan en caché tenga la misma configuración que SSMS, por lo que usa el plan en caché, pero con la configuración opuesta, su código C# está forzando una recompilación (o tal vez está golpeando un realmente MALO plan en el caché), lo que sin duda puede dañar el rendimiento en muchos casos.
Si ya está llamando a un procedimiento almacenado (no publicó su consulta, aunque creo que tenía la intención de hacerlo), puede intentar agregar OPCIÓN (RECOMPILAR) a la consulta (o consultas) infractora en el procedimiento almacenado. Esto significará que esas declaraciones siempre se recompilarán, pero podría evitar el uso del mal plan que parece estar golpeando. Otra opción es asegurarse de que cuando se compila el procedimiento almacenado, el lote se ejecuta con SET ARITHABORT ON.
Finalmente, parece estar preguntando cómo puede cambiar la configuración de ARITHABORT en SSMS. Creo que lo que querías preguntar es cómo puedes forzar la configuración de ARITHABORT en tu código. Si decide continuar enviando SQL ad hoc desde su aplicación C#, entonces, por supuesto, puede enviar un comando como texto que tenga varias declaraciones separadas por punto y coma, por ejemplo:
SET ARITHABORT ON; SELECT ...
Para obtener más información sobre por qué ocurre este problema, consulte el excelente artículo de Erland Sommarskog:
- ¿Lento en la aplicación, rápido en SSMS? Comprender los misterios del rendimiento
