January 11, 2013 at 10:58 am
Hi,
I've been running the following script to capture plan usage stats.
SELECT DB_NAME(st.dbid) DBName
,OBJECT_SCHEMA_NAME(st.objectid, dbid) SchemaName
,OBJECT_NAME(st.objectid, dbid) StoredProcedure
,MAX(cp.usecounts) Execution_count
,cp.plan_handle
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
WHERE DB_NAME(st.dbid) IS NOT NULL
AND cp.objtype = 'proc'
GROUP BY cp.plan_handle
,DB_NAME(st.dbid)
,OBJECT_SCHEMA_NAME(objectid, st.dbid)
,OBJECT_NAME(objectid, st.dbid)
In my results I see the same stored procedure using 2 different plans, I'm curious as to why. Initially I figured the plan was updated and now it's using the new but I see execution counts increasing for both.
I'm not trying to solve any issues here i'm running this script to determine what sprocs are still in use, mostly just curious if anyone knows why a sproc would use 2 different plans?
thanks
January 12, 2013 at 10:08 pm
That can be caused by two sessions executing the proc with different SET options, e.g. ARITHABORT. Each execution plan has within it the set of server options that are set. Since those server options can affect behavior SQL Server must generate a new plan and both are cached and re-used where possible.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
January 14, 2013 at 10:30 am
Ok that makes sense, I figured it was something along those lines but just wasnt sure.
thanks for the reply
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply