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)