He writes:

We got into this due to different query plans coming from a VB or a web app than what was seen when running the same query from Management Studio. Eventually tracked this down to a difference in the set options predominatley whether Arithabort was on or off.

Read more to see his query.

Click here to see the execution plan of currently running queries.

SELECT TOP 10 creation_time, last_execution_time,  last_worker_time / 1000 as [Last Worker Time (ms)] ,min_worker_time / 1000 as [Min Worker Time (ms)], 
      max_worker_time / 1000 as [Max Worker Time (ms)],
    total_worker_time/execution_count/1000 AS [Avg Worker Time (ms)],
    execution_count, 
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
    ((CASE statement_end_offset 
        WHEN -1 THEN DATALENGTH(st.text)
        ELSE qs.statement_end_offset 
        END 
            - qs.statement_start_offset)/2) + 1) as statement_text,plan_generation_num ,query_plan, Plan_handle
FROM sys.dm_exec_query_stats as qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle)
-- where st.text like '%proc name to be searched for%'
ORDER BY execution_count DESC;

--- Determine options used at run time

select  * from sys.syscacheobjects with (nolock) where sql like '%proc to be searched for%' and objtype='proc'


select dbo.fn_setopts(249)

/*
 This contains a bitmap containing the SET options relevant to each cached plan for a proc.
The following function can be used to decipher this bitmask:
*/

 

create function dbo.fn_setopts(@setopts int)
returns nvarchar(4000)

as
begin

declare @s nvarchar(4000)
select @s='Options: '
if @setopts & 1    > 0 select @s = @s + N'ANSI_PADDING, ' 
if @setopts & 2    > 0 select @s = @s + N'max degree of parallelism, '
if @setopts & 4    > 0 select @s = @s + N'FORCEPLAN, ' 
if @setopts & 8    > 0 select @s = @s + N'CONCAT_NULL_YIELDS_NULL, '
if @setopts & 16   > 0 select @s = @s + N'ANSI_WARNINGS, '
if @setopts & 32   > 0 select @s = @s + N'ANSI_NULLS, '
if @setopts & 64   > 0 select @s = @s + N'QUOTED_IDENTIFIER, '
if @setopts & 128  > 0 select @s = @s + N'ANSI_NULL_DFLT_ON, '
if @setopts & 256  > 0 select @s = @s + N'ANSI_NULL_DFLT_OFF, '
if @setopts & 512  > 0 select @s = @s + N'NO_BROWSETABLE, '
if @setopts & 1024 > 0 select @s = @s + N'TriggerOneRow, '
if @setopts & 2048 > 0 select @s = @s + N'ResyncQuery, '
if @setopts & 4096 > 0 select @s = @s + N'ARITHABORT, '
if @setopts & 8192 > 0 select @s = @s + N'NUMERIC_ROUNDABORT, ' 

return @s

end

You do not want to force SQL Server to use a particular execution plan, because SQL Server can pick different execution plans depending on how much data will be processed. When it processes a few rows, it will choose a plan that is optimized for a few rows (and typically use nested loops). If the same script processes a lot of rows, it will use a plan that is optimized for a lot of rows (and use merge joins or hash joins). By forcing SQL Server to use single execution plan, you prevent it from using the most efficient execution plan for different scenarios.

But what happens if SQL Server estimates the wrong number of rows? The worst thing it can do is estimate few rows, use an execution plan optimized for a few rows, and actually process a large number of rows. In this scenario, you will find a very slow query.

I found an easy fix for this situation. Use the OPTION(HASH JOIN, MERGE JOIN) modifier to any SELECT, INSERT, UPDATE, or DELETE statement. For instance:

UPDATE cust
SET CustomerSourceID = th.SourceID
FROM Customer cust
INNER JOIN TransactionHeader th ON th.CustomerID = cust.CustomerID
WHERE cust.CustomerSourceID IS NULL
OPTION (HASH JOIN, MERGE JOIN)

The OPTION (HASH JOIN, MERGE JOIN) modifier does not allow SQL Server to use nested loops. Since nested loops are typically efficient for a small number of rows, this causes SQL Server to optimize your query for a large number of rows. Even if this query encounters a few rows, the plan will be moderately efficient.

The good thing about OPTION (HASH JOIN, MERGE JOIN) is

• It does not require a statement to be restructured.
• It will not likely introduce any bugs.

The bad thing about it is

• You prevent SQL Server from selecting the best execution plan for all scenarios. The plan will be optimized for a large number of rows.

Update: Here is a query to get the execution plan of the most frequently used queries.

Getting the SQL Server execution plan from a production can be difficult, since you are not running the code within Enterprise Manager. You can still get the execution plan of any running statement and display the graphical representation in Enterprise Manager.

If your script is currently running, you can lookup its execution plan in the plan cache. The steps are:

1. Run a query to get the the plan_handle of currently running code
2. Lookup the execution plan for the plan_handle.

The first query is:

SELECT
sder.session_id AS [SPID],
sder.sql_handle as [SQL_Handle],
sder.plan_handle as [PLAN_Handle],
sdes.login_name AS [Login],
sd.name AS [DBName],
sder.start_time AS [Start Time],
sder.status AS [Status],
sder.command AS [Command],
sdet.text AS [SQL Text],
sder.percent_complete AS [Pct Cmplt],
sder.estimated_completion_time AS [Est Cmplt Time],
sder.wait_type AS [Wait],
sder.wait_time AS [Wait Time],
sder.last_wait_type AS [Last Wait],
sder.cpu_time AS [CPU Time],
sder.total_elapsed_time AS [Total Elpsd Time],
sder.reads AS [Reads],
sder.writes AS [Writes],
sder.logical_reads AS [Logical Reads]
FROM
sys.dm_exec_Requests sder
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sdet
JOIN sys.dm_exec_sessions sdes on sder.session_id = sdes.session_id
JOIN sys.databases sd on sder.database_id = sd.database_id
WHERE
sder.session_id <> @@SPID and sder.session_id > 50

The second query is:

SELECT * FROM sys.dm_exec_query_plan ( <PLAN_Handle> )
--here <PLAN_Handle> is supplied based on
--the results from the first query.

This gives you the XML execution plan that you can copy and paste into notepad, save it with a *.sqlplan extension, and double click on the file to view the graphical version of the execution plan.