Więc twój kod C# wysyła zapytanie SQL ad hoc do SQL Server, przy użyciu jakiej metody? Czy rozważałeś użycie procedury składowanej? To prawdopodobnie zapewniłoby taką samą wydajność (przynajmniej w silniku) niezależnie od tego, kto go nazwał.
Czemu? Ustawienie ARITHABORT jest jedną z rzeczy, na które zwraca uwagę optymalizator podczas określania sposobu wykonania zapytania (a dokładniej w przypadku dopasowania planu). Możliwe, że plan w pamięci podręcznej ma to samo ustawienie co SSMS, więc używa planu z pamięcią podręczną, ale przy odwrotnym ustawieniu twój kod C# wymusza ponowną kompilację (lub może trafiłeś naprawdę ZŁE plan w pamięci podręcznej), co z pewnością może w wielu przypadkach zaszkodzić wydajności.
Jeśli już wywołujesz procedurę składowaną (nie opublikowałeś zapytania, ale myślę, że chciałeś), możesz spróbować dodać OPTION (RECOMPILE) do naruszającego zapytania (lub zapytań) w procedurze składowanej. Oznacza to, że te instrukcje zawsze będą się ponownie kompilować, ale może to uniemożliwić wykorzystanie złego planu, który wydaje się być realizowany. Inną opcją jest upewnienie się, że kiedy procedura składowana jest kompilowana, partia jest wykonywana z SET ARITHABORT ON.
Na koniec wydaje się, że pytasz, jak zmienić ustawienie ARITHABORT w SSMS. Myślę, że chciałeś zapytać, jak możesz wymusić ustawienie ARITHABORT w swoim kodzie. Jeśli zdecydujesz się kontynuować wysyłanie ad hoc SQL z aplikacji C#, możesz oczywiście wysłać polecenie jako tekst, który zawiera wiele instrukcji oddzielonych średnikami, np.:
SET ARITHABORT ON; SELECT ...
Więcej informacji o przyczynach występowania tego problemu można znaleźć w świetnym artykule Erlanda Sommarskoga:
- Powoli w aplikacji, szybko w SSMS? Zrozumienie tajemnic wydajności
