5

I am working with MS SQL Server 2008 R2. I have a stored procedure named rpt_getWeeklyScheduleData. This is the query I used to look up its execution plan in a specific database:

select 
   *
from 
   sys.dm_exec_cached_plans cp
      CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
where 
   OBJECT_NAME(st.objectid, st.dbid) = 'rpt_getWeeklyScheduleData' and 
   st.dbid = DB_ID()

The above query returns me 9 rows. I was expecting 1 row.

This stored procedure has been modified multiple times so I believe SQL Server has been building a new execution plan for it whenever it was modified and run. Is it correct explanation? If not then how can you explain this?

Also is it possible to see when each plan was created? If yes then how?

UPDATE:

This is the stored proc's signature:

CREATE procedure [dbo].[rpt_getWeeklyScheduleData]
(
   @a_paaipk        int,
   @a_location_code int,
   @a_department_code   int,
   @a_week_start_date   varchar(12),
   @a_week_end_date varchar(12),
   @a_language_code int,
   @a_flag      int 
)
as
begin
   ...
end

The stored proc is long; has only 2 if conditions both for @a_flag parameter.

if @a_flag = 0
begin
   ...
end 

if @a_flag = 1
begin
   ...
end
srh
  • 1,661
  • 4
  • 30
  • 57
  • http://blog.codinghorror.com/get-your-database-under-version-control/ – DLeh Jun 16 '15 at 15:19
  • At least having different connection settings like ansi_nulls or datefirst cause several plans to be created, looking into dm_exec_plan_attributes might tell something: https://msdn.microsoft.com/en-us/library/ms189472.aspx – James Z Jun 16 '15 at 15:22
  • Do you have the recompile option in your proc definition? – Sean Lange Jun 16 '15 at 15:33
  • @DLeh we already have database under version control. We always use DROP & CREATE for a stored proc change. – srh Jun 16 '15 at 15:35
  • @srh in your original post you stated you weren't sure if it was modified using DROP or ALTER. Which one is it? – Sean Lange Jun 16 '15 at 15:38
  • @SeanLange there is no recompile option in proc definition. I was wrong about not sure if it was modified using DROP or ALTER; this proc was not written by me; the developers who have worked on it have confirmed that they always use DROP & CREATE for proc modification – srh Jun 16 '15 at 15:44

2 Answers2

4

Depending on the nature of the stored procedure (which wasn't provided) this is very possible for any number of reasons (most likely not limited to below):

  1. Does the proc use a lot of if this then this select, else this select/update
  2. Does the proc contain dynamic sql?
  3. Are you executing the SP from both web and SSMS? Then you're likely executing the SP with different connection settings.
  4. Does the stored proc have parameters? Sometimes a difference in parameters can cause one execution plan to be terrible for a specific set, so a different plan is used.

Going to try an analogy which might help... maybe...


Say you have a stored procedure for your weekend shopping. You typically need to get groceries, sometimes an air filter, and even less often a big pack of something that needs replacing 4 times a year.

  1. The grocery store can handle groceries, and is the closest to your house (5 minutes).
  2. Target can handle the air filter and groceries, but add 25 minutes travel time.
  3. "Big place of everything" has everything you'd possibly need, but is an hours drive away.

So here, depending on your parameters @needsAirFilter and @needsBigPackOfSomething could vastly change your "execution plan" of your stored procedure of "shopping".

If @needsAirFilter and @needsBigPackOfSomething is false, there's no reason to make the 30 minute or hour drive, as everything you need is at the grocery store.

One a month, @needsAirFilter is true, in that case we need to go to Target, as the grocery store's execution plan is insufficient.

4 times a year @needsBigPackOfSomething is true, and we need to make the hour drive to get the big pack of something, while grabbing groceries, and airfilter since we're there.

Sure... we could make the hour drive every time to get groceries, and the other things when needed (imagine single execution plan). But this is in no way the most efficient way to do it. In instances like this, we have different execution plans for what information/goods are actually needed.

No idea if that helps... but I had fun :D

Kritner
  • 13,557
  • 10
  • 46
  • 72
  • just updated the question to include proc's definition for parameters and conditions. The proc does not have dynamic SQL. This proc is always executed from another proc. – srh Jun 16 '15 at 15:47
  • based on the range of parameters and the if/then logic in the SP it would make sense that multiple plans exist for the SP. May I inquire as to why it matters? The engine is designed to help with planning the most optimal execution, what is the reasoning for being concerned with multiple execution plans, when there are obviously multiple paths through your stored procedure? – Kritner Jun 16 '15 at 15:54
  • Additionally check out https://technet.microsoft.com/en-us/library/ee343986(v=sql.100).aspx It has a lot of good information on execution plans, though it is quite lengthy and pretty brain ouchies in some parts. – Kritner Jun 16 '15 at 15:58
  • Thanks and awesome explanation. It really does not matter that if a proc have multiple execution plans. This question was more for my knowledge as I thought there is always 1 execution plan per stored proc. – srh Jun 18 '15 at 20:48
2

Typically SQL Server will generate a new query plan depending on the values of the parameters being passed in (this can determine what indexes, if any, it will use) and if indexes are added, changed or updated (on the tables/views being used in the proc) so SQL Server may decide that it is more effective to use one or more indexes that it previously ignored. The more involved the SQL in the proc will also kick off more work on SQL Server side as it attempts to optimize the query. If the data changes (suddenly you have many more customers in NJ and there is a query and index for states) it may decide that its going to use that index and the query plan is changed. If any of the tables or views involved in the query change (schema change) will also invalidate an existing plan and result in a new plan being generated.

benjamin moskovits
  • 5,261
  • 1
  • 12
  • 22