Stored procedure slow from application but fast in ssms

Surendra Adhikari 21 Reputation points
2020-09-10T03:17:01.393+00:00

When execution of stored procedure is slow from application but fast in ssms it is said that the cause is parameter sniffing. According to this article http://www.sommarskog.se/query-plan-mysteries.html, which is a famous article on this topic, the ssms has arithabort on but the connection from application has arithabort off. If I add set arithabort on in the procedure the execution from application also becomes fast as in ssms but the article above says that is not the solution. I do not understand why that is not the solution.

SQL Server
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
13,688 questions
Transact-SQL
Transact-SQL
A Microsoft extension to the ANSI SQL language that includes procedural programming, local variables, and various support functions.
4,625 questions
0 comments No comments
{count} votes

3 answers

Sort by: Most helpful
  1. Shashank Singh 6,251 Reputation points
    2020-09-10T06:49:44.1+00:00

    I will let @Erland Sommarskog answer to this question with authority but just quoting few lines from the same blog

    Before I go into the real solutions, let me first point out that adding SET ARITHABORT ON to your procedure is not a solution. It will seem to work when you try it. But that is only because you recreated the procedure which forced a new compilation and then the next invocation sniffed the current set of parameters. SET ARITHABORT ON is only a placebo, and not even a good one. The problem will most likely come back. It will not even help you avoid the confusion with different performance in the application and SSMS, because the overall cache entry will still have ARITHABORT OFF as its plan attribute.

    So, don't put SET ARITHABORT ON in your stored procedures. Overall, I strongly discourage from you using any of the SET commands that are cache keys in your code.

    If you ask me personally this is a "good workaround" and works for most cases. If you have SQL Server 2016 or above using Query store you can force query to use plan which runs fast and that would not need ARITHABORT ON. Before that using plan guides is the solution to get over such things.

    PS: For ordinary Joe this has mostly been the solution.

    1 person found this answer helpful.
    0 comments No comments

  2. m 4,271 Reputation points
    2020-09-10T09:32:52.907+00:00

    Hi @Surendra Adhikari ,

    Agree with @Shashank Singh . And the reply is what I want to say.
    I think the quote in the reply from @Erland Sommarskog 's article has clearly explained your doubts.

    Note:
    The default ARITHABORT setting for SQL Server Management Studio is ON. Client applications setting ARITHABORT to OFF might receive different query plans, making it difficult to troubleshoot poorly performing queries. That is, the same query might execute fast in management studio but slow in the application. When troubleshooting queries with Management Studio, always match the client ARITHABORT setting.

    And more information : set-arithabort-transact-sql

    BR,
    Mia


    If the answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  3. m 4,271 Reputation points
    2020-09-11T01:34:50.683+00:00

    Hi @Surendra Adhikari ,

    Is the reply helpful?

    BR,
    Mia

    If the answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.