Почему SET ARITHABORT ON значительно ускорит запрос?

Запрос - это один выбор, содержащий множество уровней группировки и операции aggragate. При установке SET ARITHABORT ON требуется меньше секунды, иначе это займет несколько минут. Мы видели это поведение на SQL Server 2000 и 2008.

68 голосов | спросил Jonathan Allen 18 MaramThu, 18 Mar 2010 00:02:10 +03002010-03-18T00:02:10+03:0012 2010, 00:02:10

6 ответов


54

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

У меня была та же проблема. Для меня это оказался параметр sniffing, который поначалу я не понимал достаточно, чтобы заботиться. Я добавил «set arithabort on», который исправил проблему, но затем вернулся. Затем я прочитал:

http://www.sommarskog.se/query-plan-mysteries.html

Он очистился - все в порядке. Поскольку я использовал Linq для SQL и имел ограниченные возможности для исправления проблемы, я в конечном итоге использовал руководство по планированию запросов (см. Конец ссылки), чтобы заставить запросить план, который я хотел.

ответил 27 J000000Wednesday11 2011, 10:09:52
25

Приложения .NET подключаются с отключенной опцией по умолчанию, но по умолчанию она включена в Management Studio. В результате сервер фактически кэширует 2 отдельных плана выполнения для большинства /всех процедур. Это влияет на то, как сервер выполняет численные вычисления, и поэтому вы можете получить совершенно разные результаты в зависимости от процедуры. Это действительно только один из двух распространенных способов, с помощью которых proc может получить страшный план выполнения, а другой - параметр sniffing.

Взгляните на http: //sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Effects-Stored-Procedure-Performance.aspx для более подробного обсуждения этого вопроса.

ответил Ben Hoffman 18 MaramThu, 18 Mar 2010 00:09:47 +03002010-03-18T00:09:47+03:0012 2010, 00:09:47
20

Я бы сказал, что это был почти наверняка параметр sniffing.

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

В этом случае (для SQL2005 + и если ваша база данных не находится в режиме совместимости SQL2000 ). Если у вас есть как ARITHABORT, так и ANSI_WARNINGS OFF), вы обнаружите, что индекс не используется, поэтому может иметь сканирование, а не желаемый поиск (и некоторые накладные расходы, поскольку сохраняемый результат расчета не может быть использован). Кажется, что ADO.NET по умолчанию имеет ANSI_WARNINGS ON из быстрого теста, который я только что сделал.

Претензия в ответе Бена , что «способ, которым сервер выполняет численные вычисления», может добавить минуты к результату, который в противном случае занимает меньше секунды, просто не кажется мне правдоподобным. Я думаю, что, как правило, происходит то, что при исследовании проблемы с производительностью Profiler используется для определения оскорбительного запроса. Это вставляется в студию управления и запускается и возвращает результаты мгновенно. Единственное очевидное различие между соединениями - это опция ARITH_ABORT.

Быстрый тест в окне студии управления показывает, что при включении SET ARITHABORT OFF и выполнении запроса проблема производительности повторяется так, что она явно закрыта. На самом деле это, по-видимому, методология устранения неполадок, используемая в Gregg Stark .

Однако это игнорирует тот факт, что с этой опцией вы можете получить тот же самый плохой план из кеша .

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

Я протестировал это, выполнив тестовый запрос сначала из веб-приложения, а затем из студии управления с помощью SET ARITHABORT OFF и мог видеть, что usecounts поднимаются из нижеприведенного запроса.

SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 

Для того, чтобы этот совместный pf планировал на самом деле, все ключи кеша плана должны быть одинаковыми. Как и arithabort, некоторые другие примеры - это то, что исполняющим пользователям нужна одна и та же схема по умолчанию (если запрос зависит от неявного разрешения имен), а для соединений нужен такой же language.

Более полный список ключей кеша плана

ответил Martin Smith 18 J000000Sunday10 2010, 13:29:19
11

Я знаю, что опаздываю на эту вечеринку, но для будущих посетителей Мартин абсолютно прав. Мы столкнулись с этой же проблемой - SP работал очень медленно для клиентов .NET, в то время как для SSMS быстро пылал. Изучая и разрешая проблему, мы провели систематическое тестирование, о котором Кенни Эвитт спрашивает в своем комментарии к вопросу Мартина.

Используя вариант запроса Мартина, я искал SP в кеше процедур и нашел два из них. Глядя на планы, на самом деле это был случай, когда у АРИСТАБОРТА включен, а у АРИСТАБОРТА ОТКРЫТО. Версия ARITHABORT OFF имела индексный поиск, в то время как версия ARITHABORT ON использовала сканирование индекса для того же выхода. Учитывая параметры, поиск индекса потребовал бы поиска десятков миллионов записей для вывода.

Я очистил две процедуры из кеша, и .NET-клиент снова запустил SP, используя те же параметры (которые отличались широким диапазоном дат для клиента с большим количеством активности). СП вернулся мгновенно. В кэшированном плане использовался тот же индексный сканер, который ранее был показан в плане ARITHABORT ON, но на этот раз план был для ARITHABORT OFF. Мы запускали SP с теми же параметрами в SSMS и снова получали результаты мгновенно. Теперь мы увидели, что второй план был кэширован для ARITHABORT ON с сканированием индекса.

Затем мы очистили кеш, запустили SP в SSMS с узким диапазоном дат и получили мгновенный результат. Мы обнаружили, что полученный в кэше план имел индексный поиск, так как тот же выход был обработан с помощью сканирования (что также было поиском в исходном плане с ARITHABORT OFF). Снова из SSMS мы запустили SP, на этот раз с тем же широким диапазоном дат, и увидели ту же самую ужасную производительность, что и в исходном запросе .NET.

Вкратце, несоответствие не имело никакого отношения к фактическому значению ARITHABORT - с его включением или выключением от любого клиента, мы могли бы получить приемлемую или ужасную производительность: все, что имело значение, - значения параметров, используемые при компиляции и кэшировании план.

Хотя MSDN указывает, что сам ARITHABORT OFF может оказать негативное влияние на оптимизацию запросов, тестирование подтверждает, что Мартин прав - причина была связана с параметризацией, а результирующий план не был оптимальным для всех диапазонов параметров.

ответил mdoyle 8 J000000Monday13 2013, 18:59:01
0

Это напоминает мне ту же самую проблему, что и в SQL Server 2008. В нашем случае мы неожиданно обнаружили, что одно задание sql внезапно замедлилось (как правило, несколько секунд, а теперь 9 + минут), задание необходимо получить доступ к связанному серверу, мы добавили ARITHABORT на шаг задания, и это показалось проблемой был решен в течение нескольких дней, а затем вернулся.

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

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

Подробно, у пользователя нет разрешения на DBCC SHOW_STATISTICS (хотя пользователь может выбрать из таблицы). Согласно MSDN , это правило разрешения изменяется после sql 2012 SP1

  

Разрешения для SQL Server и базы данных SQL

     

Чтобы просмотреть объект статистики, пользователь должен владеть таблицей или   пользователь должен быть членом фиксированной роли сервера sysadmin,   db_owner, или роль фиксированной базы данных db_ddladmin.

     

SQL Server 2012 SP1 изменяет ограничения на доступ и позволяет   пользователи с разрешением SELECT для использования этой команды. Обратите внимание, что   для разрешения SELECT существуют следующие требования:   для запуска команды:

     

Чтобы проверить эту проблему, нам просто нужно запустить профилировщик в связанной   сервера и включите некоторые события в разделе «Ошибки и предупреждения», как показано ниже.

 введите описание изображения здесь>> </a> </p>

<p> Надеюсь, что этот опыт может помочь сообществу как-то. </p></body></html>

ответил jyao 16 32016vEurope/Moscow11bEurope/MoscowWed, 16 Nov 2016 21:06:52 +0300 2016, 21:06:52
-1

Просто эта проблема. Как говорят здесь люди, основной причиной является несколько планов запросов, один из которых является субоптимальным. Я просто хотел проверить, что ARITHABORT действительно может вызвать проблему сама по себе (поскольку в запросе, с которым у меня были проблемы, не было параметров, которые берут параметр, выводимый из уравнения).

ответил Alan D. Nelson 16 32016vEurope/Moscow11bEurope/MoscowWed, 16 Nov 2016 20:15:56 +0300 2016, 20:15:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132