Время ожидания запроса истекает при выполнении из Интернета, но очень быстро при выполнении из SSMS

Итак, ваш код C # отправляет специальный SQL-запрос на SQL Server, используя какой метод? Вы рассматривали возможность использования хранимой процедуры? Это, вероятно, обеспечило бы одинаковую производительность (по крайней мере, в движке) независимо от того, кто его называл.

Почему? Параметр ARITHABORT - это одна из вещей, на которую смотрит оптимизатор, когда он определяет, как выполнить ваш запрос (точнее, для сопоставления плана). Возможно, что план в кеше имеет те же настройки, что и SSMS, поэтому он использует кэшированный план, но с противоположной настройкой ваш код C # вызывает перекомпиляцию (или, возможно, вы действительно ПЛОХО plan в кеше), что, безусловно, может снизить производительность во многих случаях.

Если вы уже вызываете хранимую процедуру (вы не публиковали свой запрос, хотя я думаю, что вы это хотели), вы можете попробовать добавить OPTION (RECOMPILE) к ошибочному запросу (или запросам) в хранимой процедуре. Это будет означать, что эти утверждения всегда будут перекомпилироваться, но это может помешать использованию плохого плана, который вы, кажется, сбиваете. Другой вариант - убедиться, что при компиляции хранимой процедуры пакет выполняется с SET ARITHABORT ON.

Наконец, вы, кажется, спрашиваете, как изменить настройку ARITHABORT в SSMS. Я думаю, что вы хотели спросить, как вы можете принудительно настроить ARITHABORT в своем коде. Если вы решите продолжить отправку специального запроса SQL из своего приложения C #, то, конечно, вы можете отправить команду в виде текста, в котором есть несколько операторов, разделенных точкой с запятой, например:

SET ARITHABORT ON; SELECT ...

Дополнительные сведения о том, почему возникает эта проблема, см. В замечательной статье Эрланда Соммарскога:

• Медленно в приложении, быстро в SSMS? Понимание тайн производительности

Этот ответ включает способ решить эту проблему:

При выполнении следующих команд в базе данных от имени администратора все запросы выполняются должным образом, независимо от параметра ARITHABORT.

 DBCC DROPCLEANBUFFERS
 DBCC FREEPROCCACHE

Обновлять

Кажется, что у большинства людей эта проблема возникает очень редко, и описанный выше метод является достойным одноразовым решением. Но если в конкретном запросе эта проблема возникает более одного раза, более долгосрочным решением этой проблемы будет использование подсказок запросов, таких как OPTIMIZE FOR и OPTION(Recompile), как описано в эта статья.

У меня была эта проблема много раз раньше, но если у вас есть хранимая процедура с той же проблемой, удаление и воссоздание хранимой процедуры решит проблему.

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

Я понимаю, что это может быть не то, что хочет оригинальный плакат, но может помочь кому-то с той же проблемой.

При использовании Entity Framework вы должны знать, что параметры запроса для строковых значений по умолчанию отправляются в базу данных как nvarchar, если столбец базы данных для сравнения имеет тип varchar, в зависимости от параметров сортировки план выполнения запроса может потребовать шаг «IMPLICIT CONVERSION», который вызывает полное сканирование. Я мог подтвердить это, посмотрев на мониторинг базы данных в опции дорогих запросов, которая отображает план выполнения.

Наконец, объяснение этого поведения в этой статье: https://www.sqlskills.com/blogs/jonathan/implicit-conversions-that-cause-index-scans/

Простое использование ARITHABORT не решит проблему, особенно если вы используете параметризованные хранимые процедуры.

Поскольку параметризованные хранимые процедуры могут вызывать «анализ параметров», который использует кэшированный план запроса.

Итак, прежде чем перейти к заключению, пожалуйста, проверьте ссылку ниже.

Слон-и-мышь-или-анализ-параметров-на-сервере-sql

У меня была такая же проблема, и она была решена путем выполнения процедуры «С РЕКОМПЛЕКТАМИ». Вы также можете попробовать использовать анализ параметров. Моя проблема была связана с кешем SQL.

Если вы можете изменить свой код, чтобы исправить обнюхивание параметров, оптимизация для неизвестных подсказок - ваш лучший вариант. Если вы не можете изменить свой код, лучшим вариантом будет exec sp_recompile 'name of proc', который заставит только эту сохраненную процедуру получить новый план выполнения. Удаление и воссоздание процесса будет иметь аналогичный эффект, но может вызвать ошибки, если кто-то попытается выполнить процесс, пока он у вас был удален. DBCC FREEPROCCACHE удаляет все ваши кэшированные планы, что может нанести серьезный ущерб вашей системе, в том числе вызвать множество тайм-аутов в производственной среде с интенсивными транзакциями. Настройка arithabort не является решением проблемы, но является полезным инструментом для определения того, является ли анализ параметров проблемой.

У меня такая же проблема при попытке вызвать SP из SMSS потребовалось 2 секунды, а из веб-приложения (ASP.NET) потребовалось около 3 минут.

Я пробовал все предложенные решения sp_recompile, DBCC FREEPROCCACHE и DBCC DROPCLEANBUFFERS, но ничего не устранило мою проблему, но когда я попробовал обнюхивать параметры, это помогло и работало нормально.