SQL 2005 Reporting Services seems to process reports sequentially - sql-server

I'm trying to profile the experience of multiple users of a web application, all trying to generate reports at the same time. The reports are displayed on a web page using the report viewer control. The execution log on the report server seems to indicate that the reports are executed sequentially (one at a time).
Is this the expected behavior?
Is there a way to tweak this behavior? Maybe some configuration file on the report server. Or something in the way the requests for the reports are issued?
I know I can use report caching, and optimize the report execution itself. But I need to address the case where multiple users ask for a "fresh" copy of their report (different for each user), and the report execution takes 30-60 seconds.
Is there any other technique to speed things up?

Can you check you have accidentally checked the User Single Transaction option on the data source.

Related

Sending emails automatically using SQL Server job

I'm developing a .NET desktop application with SQL Server as the database backend. One of the requirements of the application is that if a record status, for example, remains inactive for 30 days, there will be a reminder email sent to the user associated to that record.
This could be done pretty easily within the application, as long as it is started and running. However, assume that for a certain period of time, nobody starts up the application, the reminder email won't be sent, because nothing / nodody triggers the action.
How about creating a job in SQL Server which can monitors the records and sends emails as needed? Has anyone ever done that?
Thanks a lot!
Given the requirements of your task, I suggest that you create a console program (w/ C# or VB.NET) that checks for inactive (30 days) row condition and then generates the appropriate email notification message. Then run this program every hour or so (depending on the urgency involved in detecting an inactive row condition) using a SQL Server Agent Job.
The following image shows how the SQL Server Agent Jobs are displayed in the Object Explorer for SQL Server 2008 R2.
This SO entry covers some aspects on creating a console program that runs at certain times. The SQL Server Job Agent has several scheduling options that should facilitate your needs.
You might be reluctant to create a console program for this, but you are apt to find that doing so gives you options that are simply not easily implemented with a pure SQL Server based approach. Plus, you may have future needs that require similar processing that this approach provides.

Do SSRS report subscriptions that trigger at the same time run concurrently?

If you have multiple report subscriptions that are set to be triggered at the same time will all of them start at that time and run concurrently? That is, if you have too many reports scheduled for a particular time they run the risk of using up too much system resources and failing?
Do shared subscriptions function differently?
I'm interested in the answer to this for any version of SSRS as my organisation manages environments with SSRS 2005, 2008, 2008 R2, and 2012.
I've tried searching MSDN and google but I haven't been able to find anything definitive. I would imagine that separate schedules all trigger simultaneously and run at once (competing for system resources) because SSRS is designed to run reports on-demand concurrently. But I could imagine scenarios where a shared subscription could queue the reports to run sequentially.
Is there any way to globally limit the number of concurrent report runs that can take place? I know you can limit it on a per-user basis in the RSServerConfig file.
I've found a bit of interesting info that explains how SSRS processes scheduled subscriptions:
When you create a subscription several things are added to the RS
server:
A row is placed in the Subscriptions table…
A row is placed in the Schedule and ReportSchedule tables…
A SQL Server Agent job is created…
When the subscription runs several things happen:
The SQL Server Agent job fires and puts a row in the Event table…
The RS server service has a limited number of threads (2 per CPU) that poll the Event table…
When it finds an event, it puts a row in the Notifications table and starts processing…
This if from: Troubleshooting Subscriptions: Part II...
(If I'm reading this correctly...) The reporting service will concurrently run two times the number of cores in your server when processing subscriptions. (e.g. If you have a dual-core machine RS will run 4 report subscriptions at once.)
I'm going to leave this question open awhile long in case anyone else has more information...
There is a setting in RsReportServer.config called MaxQueueThreads. I often set this to 1 or 2 to avoid flooding the server and crudely save resources for interactive SSRS users. The trade off is that one or two heavy subscription reports can choke the queue and hold up other subscriptions.
It is available in all the versions you listed. Here's the doco:
http://msdn.microsoft.com/en-us/library/ms157273.aspx

Access 2007 Report Performance

So I am developing reports in Access 2007 that use pass-through queries to retrieve data from SQL server. Some of the queries can take a second or two to run on the server side. When opening a report, in preview mode, based on one of these queries, the time required to render the report is much longer than the time required to simply run the query. I used SQL Profiler to watch what was happening and found that the underlying query is being executed multiple times (at least five) when the report runs. How can I get Access to cache the query results to increase the performance of these reports?

Sending a summary of SQL Server Agent job failures

SQL Server Agent allows you to create Notifications at the moment a Job succeeds or fails, but I'd like to create a regular notification that sends a summary of the events for those who are one step removed from server maintenance.
Is there a way to setup summary notifications that spell out which jobs failed over the last 24 hours?
There are several system stored procedures that you might be able to use or you could query directly against the system tables. If you have SSRS available then put together a report using those queries and you can have it on-demand or scheduled to be emailed to the necessary people at whatever time is right for you.
Specifically, check out sp_help_jobhistory and sp_help_jobhistory_full in msdb.
I'd be surprised if you couldn't use Google to find a demo of setting this up.

Overriding SQL Server Reporting Service Hourly Subscription

Users want to set up SSRS reports to be emailed to them. After a little googling i found this link that shows the subscription interface of Report Manager. This has almost every feature they need except, the hourly report subscription does not give them enough control. By default, they are able to set up hourly reports, and provide the desired start time, but at first glance, I don't see how they specify an end time. What I need is a way to say "Send me a report every hour between 5 and 10."
So I'm looking for one of two answers:
Is there really an end time that I'm just missing?
If not, how can I override the hourly subscription page and get and end time.
Thanks
You can write your own subscription service using the SQL Reporting Service Web Services.
You can schedule a subscription to run the job hourly and then write your own service that will pause the jobs at the time they do not want the reports.
More info here:
http://msdn.microsoft.com/en-us/library/ms154066(SQL.90).aspx
Alternatively, you could also try editing the SQL Server job parameters. When reporting services creates a "subscription" a SQL Server job is created. There are starting and ending time parameters in that interface. I haven't verified that this provides the functionality you are looking for though.
Also, if that doesn't work and you don't want to code your own subscription service as mentioned, you could try creating 5 different jobs that run daily spaced an hour apart. I know it's kind of a kludge but maybe the extra job maintenance is preferable to the extra time for coding your own service.

Resources