Então, seu código C# está enviando uma consulta SQL ad hoc para o SQL Server, usando qual método? Você já pensou em usar um procedimento armazenado? Isso provavelmente garantiria o mesmo desempenho (pelo menos no motor), independentemente de quem o chamasse.
Por quê? A configuração ARITHABORT é uma das coisas que o otimizador analisa ao determinar como executar sua consulta (mais especificamente, para correspondência de planos). É possível que o plano em cache tenha a mesma configuração que o SSMS, então ele usa o plano em cache, mas com a configuração oposta, seu código C# está forçando uma recompilação (ou talvez você esteja atingindo um RUIM plan no cache), o que certamente pode prejudicar o desempenho em muitos casos.
Se você já está chamando um procedimento armazenado (você não postou sua consulta, embora eu ache que pretendia), você pode tentar adicionar OPTION (RECOMPILE) à consulta (ou consultas) incorretas no procedimento armazenado. Isso significa que essas instruções sempre serão recompiladas, mas podem impedir o uso do plano ruim que você parece estar atingindo. Outra opção é garantir que, quando o procedimento armazenado for compilado, o lote seja executado com SET ARITHABORT ON.
Finalmente, você parece estar perguntando como pode alterar a configuração ARITHABORT no SSMS. Eu acho que o que você quis perguntar é como você pode forçar a configuração ARITHABORT em seu código. Se você decidir continuar enviando SQL ad hoc do seu aplicativo C#, é claro que poderá enviar um comando como texto que tenha várias instruções separadas por ponto e vírgula, por exemplo:
SET ARITHABORT ON; SELECT ...
Para obter mais informações sobre por que esse problema ocorre, consulte o ótimo artigo de Erland Sommarskog:
- Lento no aplicativo, rápido no SSMS? Entendendo os mistérios do desempenho
