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.
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
I'm completely stumped on this one.
We're running a pretty usual intranet app here, classic ASP frontend and SQL Server 2005 backend.
Occasionally, once/twice a week, a certain stored proc takes ~50x longer to run when I run it in the Management Studio. This slowness lasts the entire day and it inexcplicably goes away the next day.
So essentially what's happening is this: once/twice a week, when I fire up the intranet page that runs the stored procedure and displays the results, it takes roughly 115secs to run.
I then fire up SQL Server Management Studio and run the same query, which this time around takes only 3-4secs to run.
The next day, the intranet page is taking as long as SSMS to run the very same stored procedure, with nothing having been changed in the interim (not to my knowledge anyway).
Other details:
the IIS connects to SQL Server 2005 using Provider=sqloledb as the driver
the slowdown lasts the entire day, regardless of the number of active users
I can replicate the slowness by running the same query from Excel, using the same driver/connection string
I've ran a trace on the SQL server and it turns out that on those particularly slow days, the duration of the stored proc is actually longer when executed via IIS than direct query
As such, I was wondering whether any of you has encountered any similar behaviour before, if you've fond a solution to it and what would your advice be in tackling/solving it?
Thanks for your help,
Please find Trace results in .csv format below:
EventClass,TextData,ApplicationName,CPU,Reads,Writes,Duration (s),ClientProcessID,SPID,StartTime,EndTime
12,exec spStubbornProc,Internet Information Services,"106,016","7,059,999",1,115.80,5476,85,18/04/2013 08:17:15,18/04/2013 08:19:11
12,exec dbo.spStubbornProc,Microsoft SQL Server Management Studio - Query,"3,141","146,051",0,3.40,5876,84,18/04/2013 08:20:45,18/04/2013 08:20:48
12,exec dbo.spStubbornProc,Microsoft SQL Server Management Studio - Query,"2,563","147,387",0,2.93,5876,84,18/04/2013 08:21:04,18/04/2013 08:21:07
12,exec spStubbornProc,Internet Information Services,"103,156","7,083,365",7,118.73,5476,80,18/04/2013 09:39:41,18/04/2013 09:41:40
12,exec dbo.spStubbornProc,Microsoft SQL Server Management Studio - Query,"2,406","175,029",1,2.57,5876,84,18/04/2013 10:08:58,18/04/2013 10:09:01
12,exec spStubbornProc,Internet Information Services,"112,218","7,103,267",7,114.72,5476,75,18/04/2013 14:06:26,18/04/2013 14:08:21
12,exec spStubbornProc,Internet Information Services,"93,515","7,101,229",3,93.60,6092,60,18/04/2013 19:37:02,18/04/2013 19:38:35
12,exec spStubbornProc,Internet Information Services,"2,500","148,775",1,3.42,5160,75,19/04/2013 09:16:01,19/04/2013 09:16:04
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