We have a database hosted in SQL Azure that we connect to through a Cloud Service webapp. Every once a while, one specific stored procedure that returns 100 rows throws a timeout exception when ran from the actual webapp. When we run the same stored procedure with the same parameters from the SQL Management Studio we get the actual results. This issue persists for a while and sometimes disappears as fast as it occurred.
Other stored procedures and data retrieval from our application works like a charm, but one specific SP has this issue, which is weird. When the issue occurs, we can temporarily fix it by adding something like WHERE 1=1 into the where clause. Then it works for a while, but at some point the whole things starts all over again. I cannot get a grip on what's going wrong here or what could be causing this. We also added WITH RECOMPILE to the stored proc, but to no avail.
I experienced the same thing with mine. I checked the execution plan and everything looked fine. So I copied the database to my local machine and it ran there without any problems. Finally I decided to drop and recreate the stored procedure that was timing out. After doing that, the SP ran normally again with no timeouts.
We have the same issue especially after upgrading or downgrading a server. We found that a quick alter including "with recompile" fixes the problem. We turn recompile off after we've altered it once. Not sure if Azure gets some kind of corruption in the execution plan or what is happening. Not convinced you need "with recompile" you may just need to do the alter.
Related
In SQL Server 2016, a stored procedure is throwing an error when it's executed from my .Net application. And when we execute the same stored procedure in the database with the same input parameters, there is no error.
After altering the stored procedure without changing any logic, it again starts work normally for sometime. Frequently we are facing this issue.
Any suggestion to fix this issue permanently?
We ran into the same exact thing. The stored proc ran fine in the db but took forever or timed out when ran from the app.
In the end it came down to parameter sniffing and having bad plans in the cache. The quick and dirty fix is to recompile the stored proc using the 'with recompile' option. We eventually just re-wrote the proc.
Anyways, this article is very good at explaining how SQL Server uses parameter sniffing, why it is a good thing until it is not.
Happy hunting!
Environment:
ASP.NET MVC 5.2.3.0
SQL Server 2014 (v12.0.2000.8)
Entity Framework 6
hosted on Azure
We have one page that gets data from the database using a stored procedure.
Lately we’ve noticed that some time this page loads about 20 secs. So we started to investigate the problem. I’ve tried to execute this stored procedure directly from Management Studio and it took 150 ms+-:
So next thing I did is create a console application that connects to the Azure SQL database and executes this stored procedure:
I've also tried to use SqlQuery from EF 6:
Same thing.
Important thing: this is not permanent problem. Sometimes this problem occurs, sometimes it works just fine - 50/50.
I've checked the database load in the Azure portal - it is about 50% dtu usage (during this performance issue). But I don’t think this is related to database load because it executes fast from Management Studio.
Currently I have no idea what is the problem so I need help. I would like to notice that a lot of employees use this page (that executes the stored procedure) all the time. Maybe this is somehow related to problem.
So question: why does it take so long to execute this stored procedure using ado.net / EF?
Do some debugging.
Potential culprits include, mostly:
Database side locking that is not released fast, making a SP waiting.
Parameter sniffing where a query path is not optimal for a specific set of parameters (which may lead to locking blocking you). This is a SP problem - someone does not write proper SQL for cases like that.
The info you give is irrelevant. See... SP's are NOT EXECUTED IN EF6 - EF6 fowrards them to ADO.NET which sends them to the database. As you say they work slow, IN THE DATABASE, any C# level debugging is as useless as the menu from my local Pizzeria for this particular question. YOu have to go down and debug and analyze what happens on the database.
The SSMS screenshot you provide is totally useless - you need to run the SP in SSMS, for a case it happens, and then use.... the query plan and proper nalaysis traces to see what happens.
While I'm relatively new to SQL Server, I've been working with the SQL language and databases for over two decades, and I've got a real noodle scratcher.
A stored procedure that had been working fine for years suddenly stopped working. The procedure used a series of Insert Into #TempTables that were references further down in the procedure. Again, for years, this worked fine. Then suddenly, the other day, we started getting invalid column errors on the last couple of queries based on temp tables created before it. I know SQL doesn't necessarily run procedurally, but this query ran reliable just fine before now, so something strange is afoot.
Now, if I run each query of the procedure individually in order, I'm able run the entire procedure without error - it was only when the procedure was called from the front end (or when debugging a different procedure that called the offending procedure) that the error would occur.
After a quick search, I concluded that the best solution would be to do away with the temp tables, and simply nest the queries as sub queries in the "From" expression, eliminating the procedural nature of the procedure. Once I did that, the procedure ran fine.
But my question is - why would something that worked fine for ages suddenly stop working? This is what is troubling me, and more importantly, my boss.
There were no updates made to SQL Server around the time the procedure stopped working, so I don't think it's related to that. And while there has been additional data added, I'm still hard-pressed to believe that we broke that camel's back where the procedure suddenly stopped working. (I confirmed this by running the procedure on a restored version of the data from the last time it ran successfully; the procedure still errored out.)
Anyone seen this before?
Thanks for the feedback!
Sometimes queries that normally take almost no time to run at all suddenly start to take as much as 2 seconds to run. (The query is select count(*) from calendars, which returns the number 10). This only happens when running queries through our application, and not when running the query directly against the database server. When we restart our application server software (Tomcat), suddenly performance is back to normal. Normally I would blame the network, but it doesn't make any sense to me that restarting the application server would make it suddenly behave much faster.
My suspicion falls on the connection pool, but I've tried all sorts of different settings and multiple different connection pools and I still have the same result. I'm currently using HikariCP.
Does anyone know what could be causing something like this, or how I might go about diagnosing the problem?
Do you use stored procedures or ad-hoc queries? On reason to get different executions when running a query let's say in management studio vs using stored procedure in you application can be inefficient cached execution plan, which could have been generated like that due to parameter sniffing. You could read more about it here and there are number of solutions you could try (like substituting parameters with local variables). If you restart the whole computer (and SQL Server is also running on it), than this could explain why you get fast queries in the beginning after a restart - because the execution plans are cleaned after reboot.
It turned out we had a rogue process that was grabbing 64 connections to the database at once and using all of them for intense and inefficient work. We were able to diagnose this using jstack. We ran jstack when we noticed the system had slowed down a ton, and it showed us what the application was working on. We saw 64 stack traces all inside the same rogue process, and we had our answer!
I get a problem with SQL Server 2005, where a stored procedure seems to randomly hang/lock, and never return any result.
What the stored procedure does is to call a function, which in turn makes a union of two different functions – returning the same type of data, but from different criteria. Nothing advanced. I don’t think it’s the functions hanging, because there are other SPROCs that call the same functions without a problem, even when the first one has locked up.
After the SPROC hangs, any further attempts to call it will result in a time out – not in the call itself, but the response time will be too great, as no result is returned the code will throw an exception.
It has happened at least three times in two months in a relatively low-load system. Restarting SQL Server solves the situation, but I don’t regard that as a “solution” to the problem.
I’ve looked for information, and found something about the query cache going corrupt. However, that was in regard to dynamic SQL strings, which my problem is not. I guess it could still be the query cache.
Has anyone had the same problem, and if so, what did you do about it (don’t say “restart SQL Server every morning” ;) )? Is there any way of debugging the issue to try and find exactly what and where things go wrong? I can’t recreate the problem, but when it appears again it would be good if I knew where to take a closer look.
I don't think it makes any difference, but just for the record, the SPROC is called from .NET 3.5 code, using the Entity Franework. I say it doesn't make a difference, because when I've tested to just execute the SPROC directly from SQL Server Management Studio, no result is returned either.
It's most likely parameter sniffing
Restarting SQL server clears the plan cache. If you rebuild statistics or indexes the problem will also go away "ALTER INDEX" and "sp_updatestats"
I suggest using "parameter masking" (not WITH RECOMPILE!) to get around it
SO answer already by me:
One
Two
Are your STATISTICS up to date? One of the common causes of an cached query plan that is incorrect, is out of date statistics.
Do you have a regularly scheduled index rebuild job?
Did you verify the SQL Server log..? Defenetly the cause for the problem is been logged.. atleast you can get some hint about that. pls check that.
This excellent MSDN Article SQL Server technical bulletin - How to resolve a deadlock
explains the steps needed to identify and resolve the deadlock issues in very detail.