Sql Runs Slow In Ssrs, But Fast In Ssms

I have this query: Select '' as name, '' as pid, '' as type union all Select distinct instructor.name as name, instructor.

Solution 1:

As discussed in the comments, let's get rid of the parameters to see if your query is getting affected by parameter sniffing.

To do this we build the SQL statement from scratch. Most things in SSRS can be expressions including the SQL query so you can build it as a string. With the parameters, we'll convert them to a comma delimited list using JOIN.

So for your SQL statement, go into the Dataset Properties dialogue (not the query editor) and press the fx expression editor button to edit the query expression as text and make it be an expression as per below:

="Select '<ALL>' as name, '<ALL>' as pid, '<ALL>' as type "
&"union all "
&"Select distinct instructor.name as name, instructor.Pid as pid, instructor_type as type " 
&"From sisinfo.dbo.SISCRSI instructor "
&"inner join section_info as section on section.sctn_id_code = instructor.sctn_id_code "
&"Where section.sctn_term_code in (" &Join(Parameters!Terms.Value, ",") & ") "
&"and section.subj_code in (" &Join(Parameters!Subject.Value, ",") & ") "
&"order by name "

What we have done here is turn the SQL expression into a string where we supply the multivalue parameters as strings rather than parameters, thereby eliminating parameter sniffing as a cause of a slow running query.

If your query is slow after this, you know it isn't parameter sniffing that is the problem but at least you will have dismissed it as a cause.

Solution 2:

There's a couple of options I tried when I came across the same thing.

First was to change the parameters for variables in the stored procedure, and then use those new variables in your query.

Declare@TermsNew DataType =@TermsDeclare@SubjectNew DataType =@SubjectSelect'<ALL>'as name, '<ALL>'as pid, '<ALL>'as type
unionallSelectdistinct instructor.name as name, instructor.Pid as pid, instructor_type as type  
From sisinfo.dbo.SISCRSI instructor
innerjoin section_info as section on section.sctn_id_code = instructor.sctn_id_code
Where section.sctn_term_code in (@TermsNew) and section.subj_code in (@SubjectNew)
orderby name

Another option that has already been suggested here is to add

Option(Recompile);

at the end of your query to recompile the execution plan.

The thing that worked for me though having tried the above... If you're pulling big result sets make sure that in the tablix properties that it is not set to "Keep results on one page if possible". I turned that off and my report went from 70 seconds to 7.

Solution 3:

Actually, it turns out that this query was not the one bogging down, it was another one that was running at the same time (I think SSRS can run multiple queries at once). I thought it was the posted one as it was populating a field. Thanks for all the suggestions, I will probably wind up using them in the future.

Solution 4:

This sounds like parameter sniffing to me - I see this all the time when the SELECT is at all complex. I would add the OPTION (RECOMPILE) hint to the end of your SQL.