Это - то, что я изучил так далеко от своего исследования.

.NET отправляет в настройках подключения, которые не являются тем же как, что Вы получаете, когда Вы входите в систему студии управления. Вот то, что Вы видите, осуществляете ли Вы сниффинг соединения с профилировщиком SQL:

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed  

я теперь вставляю тех, которые начинаются выше каждого запроса, который я выполняю, когда зарегистрированный к SQL-серверу, чтобы удостовериться, что настройки являются тем же.

Для этого случая, я попробовал каждую установку индивидуально, после разъединения и повторного подключения, и нашел что, изменившись arithabort от прочь до на уменьшенном проблемный запрос от 90 секунд до 1 секунды.

самое вероятное объяснение связано со сниффингом параметра, который является SQL-сервером техники использование для выбора то, что это думает, самый эффективный план запросов. При изменении одной из настроек подключения оптимизатор запросов мог бы выбрать различный план, и в этом случае, это, по-видимому, выбрало плохой.

, Но я не полностью убежден в этом. Я попытался сравнить фактические планы запросов после изменения этих настроек, и я должен все же видеть различное шоу любые изменения.

там что-то еще об установке arithabort, которая могла бы заставить запрос работать медленно в некоторых случаях?

решение казалось простым: Просто поместите набор arithabort на в верхнюю часть хранимой процедуры. Но это могло привести к противоположной проблеме: измените параметры запроса, и внезапно это работает быстрее с 'прочь', чем 'на'.

В настоящее время я работаю, процедура 'с перекомпилировали', чтобы удостовериться, что план повторно создан каждый раз. Это хорошо для этого конкретного отчета, так как требуется, возможно, секунда для перекомпиляции, и это не слишком примечательно на отчете, который занимает 1-10 секунд для возврата (это - монстр).

, Но это не опция для других запросов, которые работают намного более часто и должны возвратиться как можно быстрее во всего нескольких миллисекундах.