My company has a process where data gets moved from one DB to a completely different DB. When a stored procedure gets called, it calls a bunch of other stored procedures and also passes through some triggers. I have a value that is being inserted incorrectly and I'm just trying to find out where the value is being calculated wrong. I tried using Profiler, but have had little success in isolating they problem.
Is there a way to set breakpoints for every step without opening up hundreds of stored procedures and triggers and manually toggling on breakpoints on every line?
Ideally, I'd like to only step through lines that modify a particular variable, but I'll settle for tracing through everything. This is SQL Server 2008 R2.
It sounds like you might benefit from simply executing the stored proc in a debugger. You can inspect variables while the code is being stepped through.
This is probably easiest/slickest to do using Visual Studio. This is the MS article on doing that -- it is pretty simple to do, esp. if you already know how to debug code in VS.
Related
We have a very strange problem:
We have a stored procedure which returns a set of data. This procedure does a rather complex join and aggregation, so it takes 700 Milliseconds to execute.
When called directly in SQL Studio, the procedure ALWAYS returns correcty and always takes about 700 ms of time.
However, when called via a Client software (C# or Excel), then it works for a while, but then suddenly, the procedure takes 30 seconds (!) and gets a timeout. The number of disk reads is normal, but CPU is going up.
This behaviour goes on for 1-2 hours, and then it is normal again ! During this time, when the procedure show this behaviour, you can still execute the procedure in SQL Studio. Also, other and more simple procedures also get normally executed when called in the client.
I checked the calls with the profiler. When calling via a client, the call is marked as "RPC", when called in SQL Studio, it is "SQL"
So probably the procedure executes normal, but the data transmission via RPC somehow is hanging. But this is only a guess.
Does anyone have a idea, or can point us in some direction? I don't know where to look.
Also the Event log is empty.
Problem solved -- it was a fairly complex function, and compiling the execution plan took a lot of time. I simplified the procedure by removing a lot of conditional branches (if, case) and splitting the procedure into multiple sub-procedures.
.NET applications uses predefined (default) command timeout values.
This duration is most probably not enough for some of your commands and queries.
You may try to define your custom command timeout in your application.
I think you use a C# application as mentioned. Following definition in a constructor of your database context (EF code-first approach) may solve your issue.
public MyDBContext()
: base("MyDB")
{
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = 300;
}
I've been using this definition in my C# based applications together with EF that executes sql server stored procedures.
Good luck!
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.
I have a problem with this one stored procedure that works 99% of the time throughout our application, but will time out when called from a particular part of the application.
The table only has 3 columns and contains about 300 records. The stored proc will only bring back one record and looks like this
"Select * from Table Where Column = #parameter"
When the sp is executed in management studio it takes :00 seconds.
The stored procedure is used a lot in our application, but only seems to time out in one particular part of our program. I can't think of any reason why such a simple sp would time out. Any ideas?
This is a vb.net desktop application and using sql server 2005.
You've got some code that's already holding a lock on the table so it can't be read.
try
SELECT * FROM Table WITH (NOLOCK) WHERE Column = #parameter
We had a very similar problem, we had several stored procedures that would keep timing out in the application (~30 sec), but run fine in SSMS.
The short term solution that we used was to re-run the stored procedures which fixed the problem temporarily. If this also fixes the problem temporarily for you, then you should investigate parameter sniffing problems.
For futher information see http://dannykendrick.blogspot.co.nz/2012/08/sql-parameter-sniffing.html
you need to get performance metrics. Use the sql profiler to confirm that the SP is slow at that time or something else. If it is the sql that's slow at that time - consider things like locks that may be forcing your query to wait. Lets us know and we might be able to give more specific information at that point.
If it not the SP but say the VB code, a decent profile like RedGate's Ants or JetBrains' DotTrace may help.
What is the best way to get stored procedure useage data on a specific database out of SQL Server 2000?
The data I need is:
Total of all stored procedure calls over X time
Total of each specific stored procedure call over X time.
Total time spent processing all stored procedures over X time.
Total time spent processing specific stored procedures over X time.
My first hunch was to setup SQL Profiler wiht a bunch of filters to gather this data. What I don't like about this solution is that the data will have to be written to a file or table somewhere and I will have to do the number crunching to figure out the results I need. I would also like get these results ober the course of many days as I apply changes to see how the changes are impacting the database.
I do not have direct access to the server to run SQL Profiler so I would need to create the trace template file and submit it to my DBA and have them run it over X time and get back to me with the results.
Are there any better solutions to get the data I need? I would like to get even more data if possible but the above data is sufficient for my current needs and I don't have a lot of time to spend on this.
Edit: Maybe there are some recommended tools out there that can work on the trace file that profile creates to give me the stats I want?
Two options I see:
Re-script and recompile your sprocs to call a logging sproc. That sproc would be called by all your sprocs that want to have perf tracking. Write it to a table with the sproc name, current datetime, and anything else you'd like.
Pro: easily reversible, as you'd have a copy of your sprocs in a script that you could easily back out. Easily queryable!
Con: performance hit on each run of the sprocs that you are trying to gauge.
Recompile your data access layer with code that will write to a log text file at the start and end of each sproc call. Are you inheriting your DAL from a single class where you can insert this logging code in one place? Pro: No DB messiness, and you can switch in and out over an assembly when you want to stop this perf measurement. Could even be tweaked with on/off in app.config. Con: disk I/O.
Perhaps creating a SQL Server Trace outside of SQL Profiler might help.
http://support.microsoft.com/kb/283790
This solution involves creating a text file with all your tracing options. The output is put into a text file. Perhaps it could be modified to dump into a log table.
Monitoring the traces: http://support.microsoft.com/kb/283786/EN-US/