- Create plenty of indexes to support your queries. In OLTP systems, we need to be more careful, since updating rows also requires updating all indexes. Therefore, we usually try to keep a balance with the number of indexes we put in place. But since these are reporting tables, it is highly desirable to create indexes to support your report queries; otherwise, the performance might be far from desirable.
- Create a few "decision support" tables and populate them with data aggregated from the big tables. I often see reports processing millions of rows and then showing just a few rows with a high level summary of data grouped by a specific criteria. In many cases, you can just run that query once (or maybe daily or weekly) and store the results in small aggregate tables. In your reports, you can then use these small tables, and the execution time is much faster. If your reports use aggregations, give this technique serious consideration.
- Reporting Services supports report caching. How does it work? When you configure a report to use caching (go to Report Properties and click on Execution), Reporting Services only executes the query once. After that, it caches the rendered report for the length of time you specified for caching. On any subsequent report requests, the report is served from the cached copy. Reporting Services creates a cached copy for each unique combination of parameters, so typically, the first person to run that combination of parameters has to wait longer. Any future requests are then returned much faster, and without going to the data source. This can be a huge time saver for reports with queries that take several minutes to execute.
- Similarly, you can configure a report to be cached and rendered from a snapshot. You can think of it as a pre-processed report. Snapshots can be scheduled to be created off hours, and then the report would be served from the snapshot. This is suitable for reports with no parameters, long execution time, and when your report does not need real-time data.
Dig Deeper on Microsoft SQL Server Performance Monitoring and Tuning
Related Q&A from Roman Rehak
Learn about working with image files in SQL Server, including advice on using queries to locate them, in this expert answer. Continue Reading
Is a license needed for a standby server if it's used for SQL Server replication? Get that answer and a comparison of SQL Server log shipping to ... Continue Reading
Learn why using a SQL Server stored procedures vs. a trigger can be a preferred method to retrieve data notification from a database field. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.