Question

I'm troubleshooting the case when a stored procedure runs great from the management studio at any time, but the same stored procedure can run terribly badly in one of the webservers, even for the same parameters. There could be a few things causing this, including blocking, etc.

I would like to leave out the possibility that 2 different plans were created with different SET options, and at least one of those plans was optimized using a combination of parameters that produced a bad plan.

Quoting Benjamin Nevarez:

"in general, query optimization is an expensive operation, and in order to avoid this optimization cost, the plan cache will try to keep the generated execution plans in memory so they can be reused. However, if a new connection running the same stored procedure has different SET options, it may generate a new plan instead...."

In order to tackle this I would like a T-SQL query that would show me all the values that have been set for the session.

Is this possible?

the following SET options will affect the reuse of execution plans:

(some of them)

DATEFORMAT
LANGUAGE
NUMERIC_ROUNDABORT
FORCEPLAN

Was it helpful?

Solution

If it's a case of different options causing different plans to be used, just check the options using sys.dm_exec_plan_attributes. If the options are not the same for a good and a bad plan, that can then be the reason.

A list of plan cache keys can be found in the following answer by Martin Smith:

What would cause parameter sniffing one one computer and not another?

OTHER TIPS

in order to tackle this I would like a T-SQL query that would show me all the values that have been set for the session.

To view the SET options for current sessions:

SELECT * FROM sys.dm_exec_sessions;
Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top