Также стоит сравнить set'ы выставляемые при установке соединения из ADO.Net с set'ами в MS SQL Management Studio?

xprof
Видел в форуме сообщения на тему, что надо смотреть параметры, задаваемые для соединения типа всяких SET ANSI_NULLS... и.т.д Как они могут влять на скорость выполнения запроса - непонимаю.
Вам действительно интересно? Тогда поспрошайте на скульном форуме, если доброхотов не найдётся я могу линком проспонсировать...
Да и не уверен я, что мои предположения верны... хотя... xprofОтбор ведется по ключевым полям типа DateTime
Вы это... как разберётесь - отпишите... :)

линк чуть пожже нагуглю, а RPC:Starting из-за sp_executesql?

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
ADO.NET query execution much slower than SQL Management Studio

How does the code look that calls and execute the proc from ADO.NET?

Niels

ADO.NET query execution much slower than SQL Management Studio - Erland Sommarskog
12-Mar-08 07:33:38
(eliperp@gmail.com) writes:

No, it pleads innosence. After all, SSMS uses it too!

This is an issue with two things:
1) Different default settings in the client API and in SSMS. Next the
query runs slow in the app, run this command in SSMS first:
SET ARITHABORT OFF - my prediction is that the query will run slow
in SSMS now as well. ARITHABORT is one of these settings that is an
attribute of the query plan.

2) Parameter sniffing. When SQL Server runs a query the first time, it
uses the input parameters as guidance to build the plan. If the
first-time run is with atypical values, you will end up with a bad
plan.

It appears in your case that the good plan is flushed for some reason,
and righty after that the query is run with different parameters. Maybe
there are some nightly task going on?
и т.п.

Доп инфо есть в BOL...
P.S.> не нашёл я статейку где всё было компактно и по полочкам...