Report running very slow compared to Query Analyzer - high TimeDataRetrieval

Question

Hi,
I have a report in SQL Reporting Services 2005 which calls a stored proc and the report takes a very long time to run and sometimes returns zero records. But when i run the stored proc in query analyzer it takes about 4 seconds!!
I have checked the execution log on the RS using the below sql:
Code Snippet
use ReportServer
Select * from ExecutionLog with (nolock) order by TimeStart DESC
It shows that i have a large amount of time for the dataretrieval (601309ms, about 10mins) and does not return any records most likely because of a query timeout:
TimeDataRetrieval  TimeProcessing  TimeRendering Source Status         ByteCount RowCount
  601309                      2227                     3                         1            rsSuccess 4916           0
The weird thing is that when i run it in query analyzer, i get about 400 records in 4 seconds !!
I dont understand what RS is doing to take up so much time like this to retrieve data.
The report is very simple - it basically returns the records straight out into a table.
The only thing I somewhat suspected was a parameter data type conflict between RS and SQL, specifically dates. I have a start and end date parameter in the report - i tried specifying this as date and string to see if it made any difference but it didn't.
Any help would be greatly appreciated.

Answer 1

Hi Mark,
I didn't say it was an issue of parameter sniffing, and I didn't point you towards the good article about that <s>. I asked you whether you had read the article, described to you earlier in the thread.
What I said was that it might be an issue of appropriate and dynamic query optimization, versus a cached query plan.  Parameter sniffing is only one of many ways that SQL Server tries to figure out how to optimize a query.  I thought the article did a good job of discussing some of what goes on during this process, and that by absorbing that you could think of ways to handle the wider issue that would be appropriate to your code.  I also pointed you to a thread in which I discussed this in more detail.
While there are truly many issues with the date controls in the default parameter interface and how they behave, I don't think that what you're experiencing with the date format is implicated in the performance issue.  I guess it *might* be if (say) there is a non-default param value in your proc but your report parameter allows nulls. 
Let's say the report server database has a different date default than your production database in your system. I have never sat down and tested this scenario and I guess it might cause problems, So we'll look at that first. 
Whether the date format is at fault is really easy to prove one way or the other, and once proven can be pretty easy to fix:
Create a test parameter that is of string type.  SQL Server is really good about dynamic conversion of string dates to date types as you probably know.
place values (formatted however you want) into this version of the parameter instead of your date control parameter.  Use valid dates, in both formats.
Does your performance change?
Do you get the right results but bad performance with US format date strings versus right results with good performance with AU date values?
Do you get the WRONG results with US format date strings, or with AU date strings?
Try additional permutations involving casting/converting in your proc.
FWIW, go ahead in the Query Analyzer and put the SAME values you see in the log into your tests there (in US format, I mean).  Do you get the CORRECT results?  Does performance change?  Hold this thought and see below.
Another thing you can do is look at the query plan as presented by the Query Analyzer when you present the arguments different ways.  See #7 above -- try presenting the date in different formats.  Does the plan show the same path and the same indexes in use each time, or are some not possible because of the way the date has to be converted?  When this happens, the issue is usually that the conversion must be done for each line compared in the filter.  You can fix this really easily in most cases by cast/convert in the procedure so that your SELECT line is only doing that work once. 
If the plans are different, and perhaps the indexes used are different and you *can't* fix it by fixing the date before the SELECT, do you need to add an index, or perhaps rebuild one?
Moving on from the date format, as I said before it may be really important NOT to go by your interactive Query Analyzer performance because what you do there may not be used by SQL Server in determining a query plan to cache and re-use.  In case you haven't read the other discussion that I pointed you to at (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1827775&SiteID=1), think about using RECOMPILE or other options that will force a more dynamic investigation of the query.
 >L<