When developing my report in BIDS, the Go to Bookmark action is pretty quick but after deploying my report to the server any bookmark click takes about 10 seconds with the "Loading" pop-up. My report is 1 (potentially long) page but it displays a lot of information so i wanted to be able to add a little index at the top. I've tried DocumentMapLabel as well but it's the same loading issue but I have no control over how gargantuan the side bar is for the tiny tree map it displays.
My query runs in less than a second so pretty much all of the time waiting is on SSRS.
Any ideas what is going on or if there are setting i can change to make it more snappy?
thanks.
well, i work remotely so i'm not on the network that the report server is on directly. After remoting into a machine that is, the bookmark feature is nearly instantaneous. I'm not sure why it matters for this feature but I suppose i'll be testing my report on the remote machine instead.
Related
I am working on an existing SSRS report. It works when viewed in a browser from the report server (~ 30 seconds load), but loads for quite a while in visual studio preview (~ 10 minutes). The queries themselves are fast, so something about the report specifically is causing the slowdown.
As for what I have tried so far, I tried deleting the cached .data file (no fix), deploying the report (works fine when deployed), recreating the data sources, as well as attempting to avoid bad query plans from parameter sniffing (see Fast query runs slow in SSRS). None of these fix the problem. The problem only happens specifically when using local preview.
Many articles describe viewing the execution log to figure out what stage the report is taking so much time in (query, data processing, rendering). I would like to do this so I can narrow down the cause, but it works fine on the report server, just not on the local preview. How can I get the equivalent execution log when running local preview, given there is no report database?
I suspect that because forcing the query plans to recompile doesn't solve the problem, and because the report works fine with the same query against the same server when deployed, that the actual problem might be some weird rendering bug. I have heard this can happen with certain pagination settings, but I want to confirm what general area this problem is in.
I'm looking at some issues with a migration of a huge amount of rdl's, the guy that has done this has shifted them and they work, so that's good.
But... if I download one of them the datasource is still the original datasource not the one he changed it to using the web interface.
If I download it, its the old db connection. If I view via the web interface it shows the correct datasource, and then... if I right click and edit through report builder (via the web interface) it shows the updated datasource.
If I save it updates it as I would expect.
Am I missing something here?
Personally, I would never edit a report via the web thing, I would always edit the file and redeploy.
Is there some way I can republish them all without opening each one and saving (I'm 85 into 450 of them and am bored shitless!)
This is both a question and a possible answer. Have you restarted your instance of SSRS? If the data source is shared, and has been modified, you shouldn't have to open the reports in the builder for them to reflect the modification, so alternatively it sounds like the connections are cached and a restart should clear that up.
Background:
We recently migrated to SSRS 2014; our source database is SQL Server 2008 R2. We ran into some performance problems on a report where it simply would stop responding and ultimately timeout after 30 minutes when rendering the report. Reviewing the execution log on the reporting server indicates that the data retrieval time is low, while the report rendering time is high. The solution our DBA discovered after a month of this problem, is to set READ_COMMITTED_SNAPSHOT ON.
This seems to have cleared up the very strange performance problem with a single report. This report would seemingly become deadlocked when users attempted to generate it. The deadlock appears to be on the temp report server database, occurs only when returning the report to the browser (IE or Chrome), and does not occur every time the report is generated, but may be occurring when multiple users are attempting to generate the report around the same time frame. The report has 3 levels of grouping, and returns a variable amount of rows for the entered parameters.
This setting (READ_COMMITTED_SNAPSHOT) seems to now have caused a secondary problem: in the navigation bar of the report, where the user can navigate through the pages on the report, initially displays 0 of 0 when an active "Next page" button. When the user clicks the "Next page" button, the browser performs a post-back (like it would if you were navigating to the next page) and refreshes the screen with the first page. Now, the navigation bar displays 1 of X.
All of our SSRS servers received READ_COMMITTED_SNAPSHOT ON, so I had asked the DBA to update my DEV server to OFF. When this was done, I re-generated all of the reports (about one dozen), and each of them initially displayed 1 of X pages, as I would have expected. Now, I question whether setting this property to ON was the correct approach for fixing the report.
I thought about whether creating a report snapshot would be a good solution, unfortunately, I don't think it is as we have users which have differing parameter selection.
Questions:
Was there a better way we should have solved the report performance problem above rather than setting READ_COMMITTED_SNAPSHOT to on?
Does READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION need to both be set to true/on if one is?
Has anyone encountered this problem related to the Navigation Bar in SSRS, and how were they able to resolve the issue?
Update:
We ultimately had to roll-back the READ_COMMITTED_SNAPSHOT setting, as it caused an entirely different error to occur. The problem outlined above, also seemed to clear itself up, with no issues reported two months in a row. Unfortunately, no one knows what was causing the issue in the first place, or what may have fixed it (possibly a hardware change).
I'm assuming you changed these settings on the source database of the reports, not the SSRS server itself (unless they are the same server). Changing the settings of READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION can have wide-ranging effects on your systems, so should be done with caution. See https://dba.stackexchange.com/questions/5014/what-risks-are-there-if-we-enable-read-committed-snapshot-in-sql-server for potential issues related to changing these settings (and also an answer to your second question).
To me it sounds like the problem is in your report query or queries, so changing these database level settings to resolve a performance problem in one report is probably overkill. I would first look at analysing your report queries and tuning them (and possibly adding missing statistics or indexes to the source database) before altering row versioning settings.
As to the navigation bar issue, perhaps the changes made to the row versioning mean the SSRS is unable to calculate the number of pages available when the page is initially loaded. However I don't know why that might happen.
I have created a report with Report Builder 3.0
I'm running it on Microsoft Reporting services 2012
When O look in the performance logs (via ExecutionLog3) I see that all 3 phases(Retrieval, Processing, Rendering) took about 2 secs. But the browser take 7+ sec to present it (and it is consistent that there is 5-10 seconds overhead), what might be the source of it?
Could be one of two things most commonly:
The problem MAY BE, not sure, that your SSRS server is recycling every 12 hours and the first report of the day may be accessing the catalog on the ReportServer, getting the site up and running and then giving you a report. Generally this is common with SSRS and sometimes may take up to a minute for the first report of the day. Generally you can create a 'keep alive' service to poke SSRS every few hours at http:// (servername)/ReportServer which is SSRS's web service. You can also I have read set a config setting on the SSRS server itself but that never worked for me so I gave up and created a keep alive service instead.
The report can be taking a long time if a developer created a lot of functions on top of the data to render it with font changes, size changes, color changes, dynamic logic. You mentioned 'Rendering' in the time you looked up but if the report is not rendering in the browser how are you seeing rendering happen faster?
Generally it is both of these things in different situations. Best way to check 2 is create a super simple report with no parameters and a simple dataset that returns a black and white grid.
I am trying to print a report that contains a bar graph using the report viewer, but running into an error. My reporting server is running SQL Server 2005 Reporting Services SP3 on Windows Server 2003 SP2.
Here are some steps that will reproduce the problem (at least for me)...
On a clean machine, I open up the
report, and it displays fine.
I then click the print button, and I
am prompted to install the
RSClientPrint ActiveX control. The
control downloads and installs fine.
I then click the print button again,
and the print dialog appears.
I select a printer, and click "OK".
A message box appears that has the
following text (including the
spelling error)...
An error occured during printing.
(0x80004005)
Any other report I try to print works fine. The only difference between this report and the other ones is that it contains a bar graph. If I remove the graph from the report, redeploy it, and then re-run it, it prints without getting that error.
As far as I know, it is not isolated to a specific machine. It happens to every customer I have talked to, and a variety of machines here in the office.
Has anyone seen anything like this? I have seen similar posts on the web suggesting to uninstall video drivers on the reporting server (thinking the GDI dlls have become corrupt ), install service packs, etc. I have tried every suggestion, but haven't found a good solution yet.
Thanks.
I ended up having to use a paid Microsoft incident on this, but it is resolved now. The issue was that I had a matrix in my report that had dynamic columns. Depending on exactly which date range you picked, the report could have n number of columns. In my case, when a date range was chosen that produced three or more of these dynamic columns, it would cause the matrix to become too large and run outside of the margins of the report.
The report would run and display fine with the matrix being too large, but the incredibly non-descriptive error would display whenever the report was printed or exported.
I resolved the issue by reducing the size of other columns and the overall font size in the report. This prevents the matrix from running off the page in the case of date ranges that produce three dynamic columns. It doesn't solve it in the general case (four or more columns will make it fail), but is good enough for my current purposes.
Microsoft didn't have a fix for the general case (such as a way to make the matrix fixed width).
I figured I should answer this in case anyone else runs across it.
-David