Параметр arithabort SQL-сервера
Я работаю с клиентом, который только что обновился с SQL 2000 до SQL 2008, и их время просмотра запросов сильно увеличилось.
Я посмотрел на виды и не видел в них ничего плохого. Когда я запускал представление непосредственно на сервере, время было в порядке. Когда я запускал через Management Studio удаленно, время идет от 2secs до около 30secs.
Итак, я попробовал эксперимент над тестовой копией, установив ARITHABORT в ON (на основе некоторых статей), и время идет и удаленно вниз.
таким образом, установка ARITHABORT кажется ответом, но прежде чем применять к live DB, я хотел бы понять, почему. Я понимаю, что это связано с уровнем серьезности нулевого деления, но почему это должно помочь с временем просмотра запросов?
6 ответов
Тим,
Я думаю, что в SQL Server 2000, Если вы установили ARITHABORT OFF, оптимизатор запросов не будет рассматривать индексированные индексы представления при разработке плана выполнения запроса. Поэтому, если лучший план использует индекс представления, это будет иметь значение. Я не знаю, так ли это все еще, но когда вы смотрите на планы запросов, вы можете специально посмотреть, упоминает ли более быстрый план индекс представления.
Я не знаю конкретной причины, по которой ARITHABORT имеет отношение к индексированным представлениям, но установленные параметры влияют на ряд вещей, и ситуация с ARITHABORT вряд ли была стабильной. Вы можете проверить этой ссылке.
также не исключено, что на некоторые из этих действий влияет уровень совместимости. Если какая-либо из обновленных баз данных была установлена на уровне 80 или 90, вы можете увидеть, действительно ли это необходимо.
пожалуйста, прочитайте этот пост http://www.sommarskog.se/query-plan-mysteries.html
Я склонен думать, что параметр ARITHABORT является красной селедкой. Отличаются ли планы запросов между тестовой и производственной системами? Являются ли ваши таблицы идентичными в данных, которые они содержат, и ваша статистика актуальна на обоих серверах с одинаковыми индексами? Сначала я проверю это.
[Это не очень хороший ответ.] Я также только что столкнулся с этим, но еще более странно то, что я не могу сейчас воспроизвести ранее плохую производительность! Даже после установки этого параметра обратно в OFF соответствующий SQL теперь работает так же быстро, как и раньше. [Я подозреваю, что кэширование теперь устранило любые различия, которые предоставил параметр.]
вы всегда должны включать ArithAbort в сеансе входа в систему по соображениям производительности. Я просто испытываю эту проблему с несколькими процессами в базе данных 2008 R2 и обнаружил, что Microsoft обновила документацию SQL server для 2012 как таковую.
, когда ARITHABORT
is OFF
, индексы на (сохраненных) вычисляемых столбцах не используется. В общем Microsoft рекомендует всегда превратить его ON
. Единственная причина это OFF
по умолчанию (в некоторых случаях) - обратная совместимость.