Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

High Performance SSRS


Published on

SQL Server Reporting Services (SSRS) is an easy-to-use tool for automating reports and creating highly visual dashboards. Although SSRS is easy to learn there are many tips and tricks that can improve your report building experience, not to mention make your reports run blazing fast!

This rapid-fire session goes over my learnings from the past six years of developing high performance SSRS reports, including topics like multivalue parameter efficiencies, how to best utilize subreports, and performing SQL CRUD operations with SSRS.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

High Performance SSRS

  1. 1. High Performance SSRS: Lessons Learned GroupBy | Bert Wagner | January 13, 2017
  2. 2. 2 These are our enemies!
  3. 3. Background ● BI developer at Progressive Insurance for 6+ years ● Primarily SQL 2008, 2012 ● Will be using StackOverflow data dump ● Slide, demos, code is available on and 3
  4. 4. Overview 1. SSRS Usage Data 2. SELECT * 3. Traffic and Specialization 4. Multivalue Parameters 5. Dealing with Parameter Sniffing 6. Explicitly Defining Property Values 7. Stored Procedure CRUD Operations 8. Dynamic SQL 9. Subreport Switching denotes demo in SSRS/SQL 4
  5. 5. 1. SSRS Usage Data ● Important to be able to measure results ○ Only way to solve “it depends” answers ● SSRS database has built in logging for analysis ○ ● Most useful metrics to look at when measuring performance: ○ Time Data Retrieval - time getting the data for report ○ Time Processing - time manipulating the data in report (sort, filter, etc…) ○ Time Rendering - time to build the report in the chose render format (HTML, Excel, PDF, etc…) 5
  6. 6. 2. SELECT * ● Brings back more data than you actually need ● Indexes suffer/hope you like table scans ● Maintainability - new columns might force changes in datasets ○ Duplicate column names might break reports ○ Overtime extra columns might be brought in that aren’t needed ● Doesn’t tell future developers anything about intentions 6
  7. 7. 3. Traffic and Specialization SQL Database SSRS Server User’s Computer Scenario #1: No work in the query, lots of work in the report. Work includes filtering, sorting, etc… 7
  8. 8. 3. Traffic and Specialization SQL Database SSRS Server User’s Computer Scenario #2: Filtering, sorting in the query, reporting server just displays the page to the user ● No filtering in the dataset ● No sorting in the tablix 8
  9. 9. 4. Multivalue Parameters 9 ● Multivalue parameters can be handled multiple different ways ○ Some are more performant than others!
  10. 10. 5. Dealing with Parameter Sniffing 10 ● Parameter sniffing occurs when differing values in the input parameters cause a sub-optimal execution plan to be chosen ● Due to the nature of SSRS report parameters, parameter sniffing is a common problem ● Solutions: ○ WITH RECOMPILE ○ OPTION (RECOMPILE) ○ OPTIMIZE FOR ○ IF/THEN
  11. 11. 6. Explicitly Defining Property Values 11 ● Any report properties not explicitly defined during render have to determined by SSRS during the processing and render steps. ● Explicitly define properties like: ○ Text alignment (don’t use General) ● Some properties have to do lots of calculating which hurts performance: ○ AutoGrow, AutoShrink ○ Image AutoSize A full list of properties and considerations can be found here: MSPPError=-2147217396#Render
  12. 12. 7. Stored Procedure CRUD Operations 12 ● It is possible to INSERT/UPDATE/DELETE on the database from an SSRS report ○ Can actually do anything that a stored procedure will allow ● There are a few things we exploit to get this to work: ○ Datasets in a report always execute - even if they call a stored procedure that inserts/updates/deletes and returns no data ○ If the data source’s “single transaction” property is enabled, datasets will execute in the order they appear
  13. 13. 8. Dynamic SQL 13 ● Dynamic SQL is a query that is built programmatically ○ This gives us lots of flexibility in terms of how we can display our data and build reports so they are reusable ● Dynamic SQL can run very efficiently or have terrible performance - use caution and ALWAYS test ● Dynamic SQL also leaves lots of room open for SQL injection - be sure to parameterize any user input you are building into your query
  14. 14. 9. Subreport Switching 14 ● Reports with lots of expressions generally take a long time to render ● If a report is using a lot of expressions, it’s sometimes possible to break them up into multiple subreports ○ The parent report decides which subreport to run (based on efficiency) ○ This comes up a lot if you are displaying data using dynamic SQL
  15. 15. Thank you! ● Session: ● Blog: ● Email: ● Twitter: @bertwagner 15