I have a problem with a query running on Microsoft SQL Server 2012.
This query selects articles out of different stores and ran fine over months, within under one second.
Several weeks ago, this query suddenly started taking a very long time to finish - 50 seconds or more - but only for one of our stores.
If I clear the query plan cache for this one SELECT statement, then the query takes less than one second to finish again.
Unfortunately, this problem occurs only very sporadically and only on our productive server, so I have no chance to analyze the problem.
I restarted the server few weeks ago and the problem did not occur until yesterday (before every three days).
Do you have any idea or tip for me to solve this problem?
It is definitely looks like a parameter sniffing issue.
Read more about Parameter Sniffing
You can try following options.
1- Use Dummy variables on SQL Server stored procedure or function used.
2- Alter SP WITH RECOMPILE Option.
3- Use hints like OPTION(RECOMPILE) or OPTION (OPTIMIZE FOR (#VARIABLE=VALUE))
4- Disable Parameter sniffing on SQL instance.
You can read more about this on MSDN for recommendation and workarounds here
Related
I have an issue with performing sql queries, that I dont know what to do about. Tried many things and many creative Google searches.
I have a website that connects (ADO.NET) to a SQL Server 14 (we switched from version 10 where everything worked). From the website a search is performed and when the search result only returns one row, then everything works fine. When the search result returns more than a single row, then I get a timeout from SQL server.
Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the
server is not responding.
The SQL query is excatly the same. Only the parameter changes.
All SQL queries works fine within SQL Management studio.
The SQL Query uses a few views and joins and is very simple with just one parameter. Within management studio it takes 2-3 seconds to complete.
If I change back to the identical database on the old SQL Server 10, then it works again.
What I have tried:
1. Checked the execution plan and its identical for both searches.
2. Changed server memory allocation.
3. sp_refresview.
4. SQL Profiler gives no warnings or raised eyebrows.
5. sp_who2 shows no blocking.
6. Changed Remote Query Timeout to 0 (no timeout).
7. Increased timeout in web.config to 120 seconds.
8. set arithabort = on.
9. set nocount = on.
Still get the timeout.
I'm so confused...
EDIT
As far as I can see, the SQL Profiler tells me that the SQL transactions completes without any problems. But for some reason the result never reaches the web server. It only happens for specific SQL Queries so for the most part everything is fine with the communication to/from the SQL Server and the web server.
Also when I run the website locally from Visual Studio, then everything works perfectly! No timeouts or anything. I only happens for SQL Query XYZ from the web server.
I have a stored procedure that takes 1 parameter. When I run the stored procedure from SQL Server Management Studio, it runs in 2-4 seconds. When I call it with a console application, it takes 30+ seconds. The SQL Server is remote and both SSMS and my application are being run from my local machine so I don't think it's a networking issue.
I've ran the SQL Server Profiler to try to track down the issue and one thing I'm seeing is that when it's run from SSMS it starts the statement, recompiles it, then starts it over again, then completes it, like this:
SP:StmtStarting
SP:Recompile
SQL:StmtRecompile
SP:StmtStarting
SP:StmtCompleted
The 2 recompile entries have an EventSubClass of "2 - Statistics changed"
From the app I only see entries for SP:StmtStarting & SP:StmtCompleted, no recompile entries.
I'm calling exactly the same stored procedure with the same parameter value. Why does SSMS recompile based on statistics but my console app does not?
After researching and troubleshooting it appears to be entirely due to SET_ARITHABORT_ON. SSMS defaults this to 'ON' while the .net sql client defaults it to 'OFF' so it was going with 2 different execution plans, although I'm not entirely sure why the two plans are so drastically different.
I overrode the OpenConnection() method to open the connection set it to ON and my application then had the same performance as SSMS. I hope this helps anyone else who stumbles upon this.
We have a stored procedure that has been working perfectly for over 10 years. A few days ago it started timing out. I run it from the Query console in SQL Management Studio and it timesout. I restart the server and then it runs in 1 second...
You should consider the changes happened to your system over these 10 years, maybe you have added some background services that is doing some heavy sql updates/insertions while you are running your query.
I think you can have a clear vision on the performance of your query if you run it on a staging server or a local machine( which normally have a different load of sql operations ), observe the time it takes to execute your query, do your tries from time to time.
If the execution time of your query on staging server is constant, then your query is not the cause of the issue.
The site is ASP.NET 2.0, using LINQ to SQL. Database is SQL Server 2008 R2.
Been working on an issue where performance suddenly took a huge drop one day and has remained that way since. Cannot figure out why. It has been just certain functionality of the site, not necessarily a site-wide problem. Have focused on a particular stored procedure in general that is taking a good 1000ms+ showing in profiler. When copying the TextData and running right in the query analyzer, it runs much quicker.
Have tried a sp_recompile on the stored procedure as well as the table used. The db server was restarted during a maintenance period and that also did not stabilize things. Is there any possible troubleshooting steps anyone could provide to help dig deeper on this? Absolutely stumped.
It could be a parameter sniffing problem. You can see the details here - http://blogs.msdn.com/b/turgays/archive/2013/09/10/parameter-sniffing-problem-and-workarounds. As suggested in the blog, you can try the following -
OPTION (OPTIMIZE FOR (#VARIABLE=VALUE))
OPTION (OPTIMIZE FOR (#VARIABLE UNKNOWN))
Use local variables - Basically declare local variables and assign the value of the parameter to local variable and use the local variable in the query.
OPTION (RECOMPILE) - Since you have already tried that you can ignore this
Could you post the query snippet which is causing this issue?
I am using SQL Server 2008 and SQL Server Management Studio.
I need to run a heavy SQL query looking through a large number of rows and doing XQuery selection. I have had to stop the execution because it ran for over 30 minutes and it apparently causes timeouts in the software system using the database.
Is there any way of showing the results as they are found instead of in the end, or can I even get some live statistics on the load?
Yes, the WITH FAST query hint allows this kind of behaviour.... it gives you a start, but the overall run time may be longer.
Andy Warren's videos are always worth watching: http://www.sqlshare.com/UsingtheOPTIONFASTQueryHint_819.aspx
Some old guidance from 2006: http://blogs.msdn.com/b/queryoptteam/archive/2006/05/03/589529.aspx