ARITHABORT OFF отрицательно влияет на производительность

Question

Я полностью понимаю, что SQL-запросы от приложений обычно используют SET ARITHBAORT OFF, где SSMS (по умолчанию) использует SET ARITHBAORT ON. Я также считаю, что SET ARITHBAORT OFF существует только для совместимости с оригиналом, и действительно запросы должны выполняться с SET ARITHBAORT ON.

У меня есть запрос, который выполняется как часть командного файла приложения консоли C#. Контекст подготовлен (по умолчанию) с SET ARITHBAORT OFF и SET ANSI_WARNINGS ON. Первые 92 вызова выполняются отлично, и 93-й всегда блокируется (каждый вызов использует разные параметры). Я смог воспроизвести это в SSMS, если я использую SET ARITHBAORT OFF до вызова хранимой процедуры с параметрами 93-го вызова.

Так что на мой вопрос (извините за справочную информацию до сих пор) .... В Erland Sommarskog article состояний:

Далее, когда дело доходит до ARITHABORT, вы должны знать, что в SQL 2005 и позже версии, этот параметр имеет нулевой эффект, если ANSI_WARNINGS включен. Таким образом, нет оснований для его включения ради этого.

Однако, я использую SQL Server 2014, и я считаю, что:

SET ARITHBAORT ON 
SET ANSI_WARNINGS ON 
EXEC mySP -- Runs efficiently 

работает нормально, но

SET ARITHBAORT OFF 
SET ANSI_WARNINGS ON 
EXEC mySP -- Runs indefinitely 

бессрочно. Поэтому, если SET ANSI_WARNINGS ON делает параметр ARITHBAORT нерелевантным, почему мой запрос блокируется? Спасибо.

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

Answer 1

OK. Таким образом, цитированное заявление, которое я вытащил из статьи Sommarsog, при условии, что уровень базы данных равен 80 или выше.

Я нашел этот пункт в MSDN reference for ARITHABORT:

Установка ANSI_WARNINGS в положение ON неявно устанавливает ARITHABORT в положение ON, когда уровень совместимости базы данных установлен на 90 или выше. Если в базе данных уровень совместимости установлен в 80 или более ранних версиях, опция ARITHABORT должна быть явно установлена ​​на значение.

Это объясняет:

1. Почему я получил разницу при смене ARITHABORT даже если ANSI_WARNINGS был установлен в ON. (Уровень базы данных был 80)
2. Почему изменений уровня базы данных появился, чтобы исправить эту проблему (потому что я изменил его до 120)

Answer 2

В статье вы Размещенная в заблуждении. Если ansi_warnings ON и arithabort выключен, вы, как человек, знаете, что это не имеет никакого отношения к вашему запросу. Двигатель сервера sql не знает, имеет ли это значение или нет, и автоматически заставит получить новый план выполнения, а не использовать ваш кеш-план.Это означает, что если у вас проблемы с параметрами нюхания и у вас плохой план, вы никогда не получите этот плохой план и не используете его при включенном аритабете. Это то, что делает этот параметр отличным тестом, чтобы найти параметр sniffing. Используйте оптимизацию для неизвестного подсказки для параметра sniffing вместо изменения уровня совместимости базы данных, который может повлиять на другие вещи.