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!
Related
I'm reviewing dozens of SQL Server 2017 stored procedure query execution plans. I just noticed that one of the stored procedures is named "getDate". The procedure "seems" to work, and according to this "getDate" isn't a reserved keyword, but I'm bothered by the potential confusion with the GETDATE() function. I don't have a lot of time right now to comb through all of the potentially impacted code modules editing calls to this stored procedure. Is this something I can ignore for now and fix later, or is it likely causing problems such that I should fix it right away? I don't see any problems, apart from (presumably unrelated) super-slow running queries--which is why I'm reviewing the execution plans.
The estimated execution plan for this "getDate" stored procedure looks OK though.
It's not recommended to keep the same name for the stored procedure. It would create so much chaos when you think long run and if you have enough time and privilege, change the name using SP_RENAME proc.
But at the same time, it would not throw error. Because GETDATE function is a database object in SQL Server and supports only SELECT or read data. What we can create is a stored procedure with the same name of database objects. So we are able to do DDL things to the user defined database objects.
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!
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.
Is there any way by which i can see how actually my stored procedure is working in SQL server management studio. When i call stored procedure from my business logic layer i want to see how it is executing step by step. It is providing me results from triggers and view can i see how it is functioning. thanks.
If I've understood you correctly, just run sp_helptext mySproc.
It will output the text of the stored procedure, which executes line-by-line (step-by-step).
You can see an example by running it on itself:
sp_helptext sp_helptext
Note: I remember there being some issues with sp_helptext the last time I used it for something advanced. Max line length is one of the issues I can remember off the top of my head.
I ended up rewriting sp_helptext myself, using the original sproc as a guideline. Unfortunately I no longer work for that company, so I don't have access to it any more.
we have a debug option in sql server management(ssms), just try it once. But I too never used this debug option.
And we can see the query execution flow and time period.
Estimated execution plan
Actual execution plan
By using the above two tings we can see the execution flow.
It may helps you..
I am experiencing a problem whereby executing a stored procedure to update a record in a table is resulting in a timeout error. I originally call my stored procedure from within an MVC3 application, which is where I first noticed the error.
However, using the SQL Server Profiler, I was able to copy the code that was generated by ADO.NET and run this directly on the database. I let this query run for approximately 5 minutes and it still didn't manage to return anything.
Here are a few facts:
The stored procedure has approximately 100 arguments that are being passed to it.
My MVC Application, SSMS and Sql Server 2008 are all installed on the same machine.
The stored procedure attempts to update a single row in a table containing about 5000 entries.
There was a trigger that would update the LastModifiedDate and CreatedDate, but I removed these triggers, and updated the EDMX to determine if there was an infinite loop caused by these triggers.
Our live server runs exactly the same stored procedure (using classic asp) as the one I am trying to run and achieves the correct result. Furthermore, the live server fails to run the same stored procedure under .NET
My machine fails to run the stored procedure for both the classic ASP and the ASP.NET
The stored procedure seems to fail only for a few of the rows, and others work perfectly fine.
I have tried changing the values of the parameters that are passed into the stored procedure
Other stored procedures work fine
There appears to be a lock on the particular table that the stored procedure was attempting to update, since executing other queries worked fine, even when waiting for this one to execute.
If anyone has any ideas on any other tests I could perform,or any tools I could use to determine the root cause of the timeout error.
Thanks.
P.S. Don't tell me to change the command timeout property, I have tried setting this to zero!
I can think of two things :
I assume you have already implemented exception handling in the stored procedure. If not, please do so, and try to get hold of the problem statement first. When you say, it happens for some rows, it might be due to bad data ? Read this for information on how to do exception handling in SQL Server 2008
Have your tried finding out whether there is a dead-lock ?
Please read this for detailed procedure and understanding.