We're using SSRS 2012 with a number of reports driven by a Query.CommandText reference to a stored procedure executing dynamic sql (sp-executesql). These are consumed from a web application where the user specifies the report, criteria, etc. After a few days, the report requests will timeout, even though the underlying stored procedure executes within a few seconds (the same stored procedure feeds a search result screen and the report). Other reports that do not use dynamic sql continue to execute fine. The only remedy we've found is to restart the SSRS service. After the initial spin-up, the same report will execute within a few seconds.
The SSRS logs don't seem point to any issue, though I'm certainly not an expert reading them. Comparing a slow to a quick one only seems to differ by the time stamps evenly spread out between the start and the end. We do see "ReportProcessingException: There is no data for the field at position xx", but on both the slow and fast runs. Running the report from the Reports portal takes about 10 minutes when it's in slow mode.
My suspicion is that some caching is going on and SSRS is influencing the SQL execution plan.
Any suggestions or requests for more specifics would be very welcome.
Related
We wanted to show data on browser from reporting server, but sometime it's failing to load and taking more than 3 mins. Is there any better approach to get the data faster.
It can be many factors why your report is slow or failing to load. First step would be analyzing executionlog (on server where is reporting services installed, database of report server, probaby ReportServer db, view ExecutionLog2). There you can see three crutial columns TimeDataRetrieval, TimeProcessing and TimeRendering
Extract from this discussion
TimeDataRetrieval - contains the sum of all DataSet durations
TimeProcessing - The number of milliseconds spent in the processing engine for the request
TimeRendering - The number of milliseconds spent after the Rendering Object Model is exposed to the rendering extension
That way you will know if you need to tune your query or your report and that's the good start.
I am trying to optimize a report for SSRS 2012 and using SQL Profiler I can see that the datasets are being processed one at a time instead of in parallel.
The checkbox to request one transaction is NOT checked.
I can't find any other setting on parallel execution.
The data source is an embedded data source.
Every item I find on the internet about parallel execution quotes a Microsoft BLOG from about a decade ago that states 2008 defaulted to parallel unless that single transaction box is checked, and the assumption is that nothing ever changes so this is still default behavior.
It would appear that the box has a different purpose since running in one transaction allows a temp table created in one dataset to be referenced in a later dataset - they are not only serialized but processed in their listed order (top to bottom). So that is about persistence of objects and data instead of parallel vs serialized.
Without the box checked it appears they are called in the order the fields are processed, but profiler results indicate that only one dataset is retrieved at a time.
So, is there a verified way to fetch multiple datasets simultaneously?
No, there aren't any other settings to control this behavior besides the one you described. Of course there are always other ways around this if efficiency is an issue for you. For example, you could look into caching the results before the report runs.
I have a weird issue with one of the data driven subscriptions on SSRS.
The subscription is a timed subscription that generates invoices (pdf/excel) and gets triggered by a stored procedure.
The issue we are facing is that the first run always takes 30-60 minutes regardless of how many invoices are being generated. Once the first run has completed the subsequent runs are completed under a minute throughout the day.
There is a second version of the same report that is run manually and it runs fine(ruling out any delays with the data extraction bit).
I have looked at some other questions here but that didnt help identify the problem:
SQL Reporting services: First call is very slow
SSRS report subscription not working sometime
Without knowing more about the query, data, database setup, other process, etc.; it will be quite difficult to say for sure. But if I had to guess, based on your description, it sounds like the query plan cache is lost and is rebuilt on the first run of the day. Without the plan the query can be less efficient. Each subsequent run will use the plan created on the first run, and will therefor run more quickly. There are a number of reasons that could cause the query plan to be wiped from cache. A recompile, other queries using too much memory, not enough system memory to begin with etc.
Hope that helps!
I've got a report in SSRS that contains two subreports, but it's taking a very long time to show the final report. According to the SSRS Execution Log, the report is spending ~140ms in data retrieval, ~20minutes in processing, and ~20ms in rendering. If I remove either of the subreports (doesn't matter which one), the time drops to ~10minutes for processing. If I remove both subreports, the time drops to ~2s. Quite obviously I have to do something about the subreports; probably try to integrate them into the main report.
Does the "TimeDataRetrieval" statistic in the execution log represent the aggregate data retrieval time for the report and all subreports, or is it just for the main report (meaning the data retrieval times for subreports are actually being added to the "TimeProcessing" stat)?
Furthermore, when I run the main report within BIDS (Visual Studio), the entire report returns in a couple seconds. Why would a report + 2 subreports render completely within a couple seconds in BIDS, yet the exact same thing takes around 20 minutes when viewed from the reporting server? They are both accessing the same SQL DB (data retrieval is only 140ms from SSRS server), and the SSRS/SQL server should have plenty of power (running in an 8-core VM that doesn't break 1% CPU usage).
I have a stored procedure that when I ran it from within the SSMS, it runs fast about 20 sec. but when I execute this same stored procedure from my .net application it takes about 50-70 secs!! Why is that happening?
Thank you.
Several reasons are possible.
First likely you are sending the data over a network, could be that it is maxed out.
Could also be that you have more users in the second scenario and so are getting locking issues.
And stored procedures that take 20 seconds when run from SSMS on a dev box (especially one which does not include the full data set of prod) are unlikely to perform well in porduction with full data sets and many more users. 20 seconds it way too long to a a query in development.
Likely your sp desperately needs to be tuned.