Риски перехода на ARITHABORT ON

Я работаю с поставщиками по соглашению, что они предоставляют основное приложение, и я могу создавать свои собственные расширения, пока я не изменяю основное приложение. Он построен в ColdFusion для подключения к базе данных SQL Server 2005.

Некоторые из построенных мной отчетов зависят от представлений, использующих функции, вычисленные из базовых таблиц, и отчеты становятся очень медленными по мере увеличения таблиц. Чтобы ускорить отчеты, я хочу использовать индексированные представления . Но после создания индексированного представления в моей тестовой среде основное приложение больше не могло вставляться в основные таблицы (оно возвращало сообщение об ошибке, ARITHABORTкоторое требуется ONпри использовании индексированных представлений).

Таким образом, кажется, что для использования индексированных представлений мне нужно иметь основное приложение SET ARITHABORT ONпри вставке / обновлении основных таблиц. Я запустил это в моей тестовой среде:

ALTER DATABASE MyDatabase SET ARITHABORT ON;

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

Существуют ли реальные запросы, которые будут нарушены SET ARITHABORT ON? Есть ли ситуации, когда было бы лучше сохранить его OFF?

TL; DR Чтобы мои новые индексированные представления работали, мне нужно настроить ARITHABORT ONвсю базу данных, но мой поставщик предупреждает, что это будет на мой страх и риск. Есть ли на самом деле риск?

Таким образом, в SET ARITHABORT ON основном говорится: «если произойдет ошибка деления на ноль или произойдет арифметическое переполнение, прервите запрос». Это обычно желаемое поведение и настройка по умолчанию для всего экземпляра. Если это вызывает проблемы с запросами вашего поставщика, я бы сказал, что они могли страдать от некоторых проблем с кодированием с самого начала. Я бы попросил у них более подробную информацию о том, почему они обеспокоены здесь.

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

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

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

Очевидный риск внесения этого изменения заключается в том, что запросы поставщика, которые ранее выполнялись правильно, могли начать выдавать ошибки или возвращать неверные результаты. Параметр ARITHABORTчастично контролирует, возвращают ли арифметическое переполнение и ошибки деления на нольNULL результат, завершают оператор с ошибкой или завершают пакет с ошибкой. То, как код поставщика может реагировать на код, который выдает ошибку вместо возврата, NULL- это не то, с чем вы бы хотели поэкспериментировать в производственной системе :)

Тем не менее, риск ниже, если уровень совместимости вашей базы данных составляет 90 или выше, и сеансы работают с SET ANSI_WARNINGS ON. Этот параметр должен был быть ONпри тестировании индексированных представлений, но вам необходимо подтвердить эффективный параметр, используемый соединениями приложения вашего поставщика. Management Studio вполне может быть настроен на использование SETпараметров, отличных от тех, которые установлены кодом поставщика при подключении (и вы не можете переопределить их с базой данных или экземплярами по умолчанию). Обратитесь к поставщику и подтвердите путем отслеживания кода поставщика с помощью SQL Server Profiler.

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

-- Recommended effective settings
SET NUMERIC_ROUNDABORT OFF;
SET ARITHABORT, 
    CONCAT_NULL_YIELDS_NULL, 
    QUOTED_IDENTIFIER, 
    ANSI_NULLS, 
    ANSI_PADDING,
    ANSI_WARNINGS ON;