We have a main stored procedure that returns around 1000 records, changes by the user permissions.
Lately the procedure performance became very bad - but only from the web-service - more than a minute!
but when running the same SP with the same parameters from ssms took only 3 seconds!!
When I tried to check the problem I added writes to log table, and immediately this change improved the performance again to 3 seconds from the web-service.
This is a mystery for me:
1. The difference between running from web-service and ssms
2. The change after adding the logging
Your issue is called parameter sniffing. There were 2 execution plans for this procedure, one created the first time you launched it from web server and another created when you lanuched it from SSMS. And the parameters of these two plans were different. The next time you execute this proc, one of this plans is used: when you execute from SSMS, the second plan is used, and from web service the first plan is used. The parameters passed to this proc were atypical when executed from wb service, and typical when executed from SSMS.
When you altered your procedure, those 2 plans were invalidated as the procedure has changed, then the new execution plan was built for SSMS and for web service, this times both plans were made for the same or similar paremeters.
If you could extract old plans from plan cache you'd see they were different and the parameters sniffed also were different while now the plans are the same and parameter sniffed are the same or similar.
Here you can read more on parameter sniffing: Slow in the Application, Fast in SSMS?
Understanding Performance Mysteries
Please do not use functions on TOP, on recordset, and, on WHERE/JOIN clauses.
When youre calling SP from SSMS, server optimizes it. But, when calling from frontend, it is huge problem. So, eliminate functions, if possible.
If you want to view about what im talking, please start profiler and then log RPC starting/completed, sql statament events. Call quantity is same, as recordset. So, assume, youre calling procedure 1000 times when usig FN on statement , returning recordset.
Related
I have an SSRS report which has seen its TimeDataRetrieval (as per the ExecutionLog3 table in the ReportingServices database) increase by 60 seconds overnight and I can't figure out why.
The report has two parameters and contains a single Dataset which passes one of those report parameters to a SQL stored procedure. I can run the stored procedure standalone in SSMS and it completes in seconds, in line with the previous report performance.
I have read many threads and articles online about how parameter sniffing affects the execution plan which SQL builds for a stored procedure when it's been called from an SSRS report versus when it is run direct, but I've tried adding an internal variable to the stored procedure, assigning the incoming parameter value to that variable and using that variable in the query within the stored procedure instead of the parameter, but this didn't make any difference to the issue. I also even tried adding OPTION(RECOMPILE) to the stored procedure, but again this had no impact.
The issue began occurring right after we upgraded our Dynamics CRM 2015 system (whose database resides on the same SQL Server as this instance of SSRS - probably a bad idea I know) to Dynamics 365, so I'm wondering if that could somehow have something to do with it, but I'm at a loss as to how to troubleshoot this one, so any suggestions would be most welcome!
Do the tables that this SP runs from steadily grow in size? Sometimes you get a 'threshold' affect where suddenly the number of rows cause performance issues. I suggest you rebuild statistics on all the tables in use and add the OPTION(RECOMPILE) and retest.
Also when trying to recreate in SSMS, you must make sure you also include all the SET options. You should capture the SQL using profiler and use exactly that, including all of the four or five set options before it (i.e. SET ARITHABORT)
You might find you can then reproduce in SSMS, in which case it is definiteley a parameter sniffing issue. (although recompile usually fixes that)
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!
We are getting timeout issues on our databases. So I trurned on SQL Server Profiler and see SQLQueryNotificationService running every second with long duration. I checked the Service Broker and there are bunch of SQLQueryNotificationService queues created. I don't think we created any of these queues also there are bunch of stored procedures like these SqlQueryNotificationStoredProcedure-15c5b84b-42b0-4cfb-9707-9b1697f44127. Could you please let me know how to drop them? If I drop them is there any impact on the database? Please let me know. I appreciate any suggestions.
Do you have an ASP.Net web site running or another application that creates Sql Server Cache dependencies? It is Sql Server Service Broker queues, it executes that WAITFOR ... statement which waits for around one minute (60000 msecs), then executes again next second. Shouldn't normally cause problems, it shouldn't block or delay your "normal" queries or stored procedures.
However, I saw it causing issues for me once - one of the stored procedures, when executed from the same web application that established the cache dependency, did timeout (or rather came back in 120 secs which is not acceptable). Exactly the same stored procedure, executed under the same account with same parameters, but from Management Studio, ran fine without any issues. It was SQL Server 2005 SP4.
SQL Profiler showed that in the middle of execution of my stored procedure (and always after the same INSERT INTO ... statement), its execution was interrupted and instead of its statement there was that WAIT FOR .... from Sql Query Notification, completed in one minute, then another WAIT FOR... starting and again, completed in 59 secs - and only after that the Profiler showed me my stored procedure completed. With the duration of 119000, which is almost exactly two minutes.
It was if that query notifications were joining the transaction within my stored procedure.
What helped: recompiled the offending stored procedure. I simply changed its script, did ALTER statement with some minor syntax changes. No problems after that.
I have a long time issue keep popping up every time.
I create ssrs report with some select query. when i try to run the report it takes around 20sec to render.
i've checked the sql profiler and indeed the query run more than 20 sec.
when i copy the query to the management studio, it runs in 0 sec.
as written in earlier posts i've tried the walk around of declaring parameters in the query and setting their value with the ssrs params. sometime it works, currently it doesn't...
any other walk around?
Configure your report to run from the cache.
Caching is a copy of the last executed report. It is not a persisted copy, it has a lifetime (like caching for 30 minutes). It is stored on the temp database. You can have only one "instance" per report (if you have parameters, you will have one per combination of parameter)
you can do that on the execution tab of the report on report manager
Make the sql statement into a stored procedure and use the WITH RECOMPILE option in the sp.
E.g.
CREATE PROCEDURE dbo.spname #ParamName varchar(30)
**WITH RECOMPILE**
AS
This will help counteract the "parameter sniffing" during the procedure execution and help improve performance.
I was wondering if you guys could help me get to the bottom of a weird problem I have recently had on SQL Server.
I have a stored procedure (lets call SPold) which is reasonably large with a lot of calculations (can't possibly do this in app as info for around 6000 users needs to come back in a one-er (I reduce this to 1000 based on Surname)). The stored procedure usually executes in a couple of seconds, and is called once every couple of minutes.
Now this morning, the stored procedure was suddenly taking 4-10 times as long to execute, causing a number of timeouts. I discovered that by making a copy of the procedure with a new name (SPnew) and executing, I would get the fast execution times again. This indicated to me that the execution plan was the problem with the original, SPold, so I decided to execute it with recompile. This would return the results a quicker (although not as fast as SPnew), but subsequent calls from users to SPold were once again slow. It was like the new plan wasn't being kept.
What I have done is to fix this is put Exec SPnew into SPold, and now calls to SPold are returning fast again.
Does anyone have any idea what is going on here? The only thing that updated overnight was the statistics, although I think that this should affect both SPold and SPnew.
Sounds like you are experiencing an incorrectly cached query plan due to parameter sniffing.
Can you post the stored procedure?
Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005
I Smell a Parameter!
In SQL Server 2005, you can use the OPTIMIZE FOR query hint for preferred values of parameters to remedy some of the problems associated with parameter sniffing:
OPTIMIZE FOR Instructs the query optimizer to use a particular value for a local
variable when the query is compiled and optimized. The value is used
only during query optimization, and not during query execution.
OPTIMIZE FOR can counteract the parameter detection behavior of the
optimizer or can be used when you create plan guides. For more
information, see Recompiling Stored Procedures and Optimizing Queries
in Deployed Applications by Using Plan Guides.
Although SQL Server 2005 does not support OPTIMIZE FOR UNKNOWN (introduced in SQL Server 2008) which
will eliminate parameter sniffing for a given parameter:
OPTION (OPTIMIZE FOR (#myParam UNKNOWN))
You can achieve the same effect in SQL Server 2005 by copying the parameter into a local variable, and then use the local variable in the query.
I've also encounterred two "strange" cases with Sql Server 2005, which might relate to your problem as well.
In the first case my procedure executed prety fast, when being run as dbo, and it was slow when being run from the application, under a different user account.
In the second case the query plan of the procedure got optimized for the parameter values with which the procedure was called for the first time, and this plan was then reused later for other parameter values as well, resulting in a slow execution.
For this second case the solution was to copy the parameter values into local variables in the procedure, and then using the variables in the queries instead of the parameters.