Ihr C#-Code sendet also mit welcher Methode eine Ad-hoc-SQL-Abfrage an SQL Server? Haben Sie die Verwendung einer gespeicherten Prozedur in Erwägung gezogen? Das würde wahrscheinlich die gleiche Leistung (zumindest im Motor) gewährleisten, unabhängig davon, wer es genannt hat.
Wieso den? Die ARITHABORT-Einstellung ist eines der Dinge, auf die der Optimierer achtet, wenn er bestimmt, wie Ihre Abfrage ausgeführt werden soll (genauer gesagt, für den Planabgleich). Es ist möglich, dass der Plan im Cache die gleiche Einstellung wie SSMS hat, also den zwischengespeicherten Plan verwendet, aber mit der entgegengesetzten Einstellung erzwingt Ihr C#-Code eine Neukompilierung (oder vielleicht treffen Sie einen wirklich BAD plan im Cache), was in vielen Fällen sicherlich die Performance beeinträchtigen kann.
Wenn Sie bereits eine gespeicherte Prozedur aufrufen (Sie haben Ihre Abfrage nicht gepostet, obwohl ich glaube, dass Sie dies beabsichtigt haben), können Sie versuchen, der problematischen Abfrage (oder Abfragen) in der gespeicherten Prozedur OPTION (RECOMPILE) hinzuzufügen. Dies bedeutet, dass diese Anweisungen immer neu kompiliert werden, aber es könnte die Verwendung des schlechten Plans verhindern, den Sie zu treffen scheinen. Eine andere Möglichkeit besteht darin, sicherzustellen, dass beim Kompilieren der gespeicherten Prozedur der Stapel mit SET ARITHABORT ON ausgeführt wird.
Schließlich scheinen Sie zu fragen, wie Sie die ARITHABORT-Einstellung in SSMS ändern können. Ich denke, Sie wollten fragen, wie Sie die ARITHABORT-Einstellung in Ihrem Code erzwingen können. Wenn Sie sich entscheiden, weiterhin Ad-hoc-SQL von Ihrer C#-App zu senden, können Sie natürlich einen Befehl als Text senden, der mehrere durch Semikolons getrennte Anweisungen enthält, z. B.:
SET ARITHABORT ON; SELECT ...
Weitere Informationen dazu, warum dieses Problem auftritt, finden Sie im großartigen Artikel von Erland Sommarskog:
- Langsam in der Anwendung, schnell in SSMS? Leistungsgeheimnisse verstehen
