Які наслідки встановлення ARITHABORT ON для всіх підключень у SQL Server?


10

Тому я визначив, що хаотична поведінка мого SQL-сервера обумовлена ​​налаштуваннями за замовчуванням .Net SqlClient Provider SET ARITHABORT OFF. Зважаючи на це, я читав різні статті, де обговорюється найкращий спосіб втілити це. Для мене я просто хочу простий спосіб, тому що SQL Server страждає, і моя настройка запитів не повністю перейшла через додаток (і, очевидно, додавання SETв sp НЕ ПРАЦЮЄ).

У блискучій статті Ерланда Соммарського про цю тему він, в основному, пропонує скористатися безпечним підходом, змінивши програму, яка видається SET ARITHABORT ONна з'єднання. Однак у цій відповіді на питання dba.stackexchange Соломон Руцький пропонує підхід як для екземпляра, так і для бази даних.

Яких наслідків мені тут не вистачає під час встановлення цього екземпляра? Як я бачу ... оскільки SSMS має цей набір ONза замовчуванням, я не бачу шкоди в налаштуванні цього ONсервера для всіх з'єднань. Зрештою, мені просто потрібен цей SQL-сервер для роботи над усім.


Читаючи більшу частину моєї відповіді, з якою ви посилалися на запитання, зараз здається, що вона за замовчуванням вимкнена, деякі клієнти спеціально вмикають її, але EF / SqlClient не торкаються її, а значить, вона залишається вимкненою.
Соломон Руцький

1
Ніякого EF, але ви піднімаєте цікаве питання щодо того, як EF може змінити налаштування на весь примірник. Отже, якщо з'єднання може змінити це, очевидно, найнадійнішим місцем для встановлення цього набору є всередині з'єднання, встановленого до SQL Server, якщо це можливо…
Ерік Свіггум,

1
"Завжди встановлюйте значення" ARITHABORT "на" УВІМКНЕНО "під час сеансів входу. Встановлення функції" АРІТАБОРТ "у ВІМКНЕНО може негативно впливати на оптимізацію запитів, що призводить до проблем з продуктивністю." Ця стаття від Microsoft пише: docs.microsoft.com/en-us/sql/t-sql/statements/…
Shiwangini Shishulkar

Я перевіряв різні сценарії, моє остаточне враження від того, що цей параметр і нюхання параметрів є друзями. Якщо є ARITHABORT OFF, то добре. Не підтримуйте всі вхідні з'єднання. (Удачі, контролюючи це). Але коли з'єднання з ним встановлено на ON, тоді SQL генерує новий план запитів, і це може вплинути на продуктивність. Мій прийом, встановіть його УВІМКНЕНО як параметр користувача за замовчуванням на рівні екземпляра і відповідно налаштуйте запити.
Ерік Свіґгум

Відповіді:


11

Є деякі параметри за замовчуванням, які існують лише тому, що ніхто насправді не знає, який був би ефект від їх зміни. Наприклад, зіставлення рівня екземплярів за замовчуванням при установці в системі, яка використовує "англійська мова США" як мова ОС SQL_Latin1_General_CP1_CI_AS. Це не має сенсу, оскільки SQL_*порівняння призначені для сумісності до SQL Server 2000. Починаючи з SQL Server 2000, ви могли фактично вибрати зіставлення Windows, і тому для англійських систем США за замовчуванням слід було змінити на Latin1_General_CI_AS. Але я думаю, що в Microsoft ніхто не знає, який вплив матиме всі різні потенційні підсистеми та системно збережені процедури тощо.

Отже, мені невідомо про якийсь конкретний негативний вплив, якщо встановити його на УВІМКНЕННЕ як як база даних за замовчуванням, так і навіть у всьому випадку. У той же час я його не перевіряв. Але навіть якби я його протестував, я, можливо, все одно не використовую ті самі шляхи коду, що і ваша програма, тому це дійсно потрібно перевірити у вашому оточенні. Встановіть його наONна рівні примірника у ваших середовищах Dev та QA, і подивіться, як це працює протягом місяця або двох. Потім увімкніть його в Staging / UAT. Якщо все продовжує йти добре протягом декількох тижнів, скрутіть цю конфігурацію на Виробництво. Головне - приділити якомога більше часу для тестування різних кодових шляхів, які не потрапляють щодня. Деякі страждають щотижня або місяці або щорічно. Деякі шляхи коду потрапляють лише в підтримку, або в якийсь спеціальний звіт або технічне обслуговування, яке хтось створив років тому і ніколи не розповідав про вас, і звикає лише через випадкові проміжки часу (так, це ніколи не буває ;-).

Отже, я провів тестування на екземплярі, який все ще має налаштування "Параметри користувача" за замовчуванням, оскільки я його ніколи не змінював.

Будь ласка, запиши:

  • @@OPTIONS/ 'user options'- значення, що маскується
  • 64 - це біт для ARITHABORT ON

НАСТРОЙКА

Я тестував як SQLCMD (для якого використовується ODBC), так і LINQPad (який використовує .NET SqlClient):

SQLCMD -W -S (local) ^
-Q"SELECT CONCAT(DB_NAME(), N': ', @@OPTIONS & 64, N' (', ses.[client_interface_name], N')') FROM sys.dm_exec_sessions ses WHERE ses.[session_id] = @@SPID;"
echo .

( ^є символом продовження рядка DOS; .останній рядок - просто змусити додатковий рядок, щоб полегшити його копіювання та вставлення)

У LINQPad:

using (SqlConnection connection =
    new SqlConnection(@"Server=(local);Trusted_Connection=true;Database=tempdb;"))
{
  using (SqlCommand command = connection.CreateCommand())
  {
    command.CommandText = @"SELECT @RetVal =
CONCAT(DB_NAME(), N': ', @@OPTIONS & 64, N' (', ses.[client_interface_name], N')')
FROM  sys.dm_exec_sessions ses
WHERE ses.[session_id] = @@SPID;";
    SqlParameter paramRetVal = new SqlParameter("@RetVal", SqlDbType.NVarChar, 500);
    paramRetVal.Direction = ParameterDirection.Output;
    command.Parameters.Add(paramRetVal);

    connection.Open();
    command.ExecuteNonQuery();

    Console.WriteLine(paramRetVal.Value.ToString());
  }
}

ТЕСТ 1: Раніше

SQLCMD повертає:

master: 0 (ODBC)

LINQPad повертає:

tempdb: 0 (.Net SqlClient Data Provider)

ВАРІАНТ ЗМІНИ ЗАБЕЗПЕЧЕННЯ

Наведений нижче T-SQL дозволяє ARITHABORTбез видалення будь-яких інших параметрів, які можуть бути встановлені, і не змінюючи нічого, якщо ARITHABORTце вже встановлено у бітовому маскуванні.

DECLARE @UserOptions INT;

-- Get current bitmasked value and ensure ARITHABORT is enabled:
SELECT @UserOptions = CONVERT(INT, cnf.[value_in_use]) | 64 -- enable "ARITHABORT"
FROM   sys.configurations cnf
WHERE  cnf.[configuration_id] = 1534 -- user options

-- Apply new default connection options:
EXEC sys.sp_configure N'user options', @UserOptions;
RECONFIGURE;

ТЕСТ 2: Після

SQLCMD повертає:

master: 64 (ODBC)

LINQPad повертає:

tempdb: 64 (.Net SqlClient Data Provider)

Висновок

Враховуючи, що:

  1. Мабуть, користі від того, щоб мати ARITHABORT OFF
  2. Користь матиме ARITHABORT ON
  3. Установка з'єднання за замовчуванням (якщо це не перекрито з'єднанням) = OFF
  4. Не видається, що або ODBC, або OLEDB / .NET SqlClient намагаються встановити ARITHABORT, таким чином вони приймають налаштування за замовчуванням

Я б запропонував змінити параметри підключення за замовчуванням для всіх примірників (як показано вище). Це було б менш нав'язливо, ніж оновлення програми. Я б оновив додаток лише в тому випадку, якщо ви виявите проблему зі зміною налаштування для всіх екземплярів.

PS Я зробив простий тест зі зміною tempdbта не зміною налаштування на весь екземпляр, і, здається, він не працює.


1
Так, після прочитання цього питання з Полом Білим на цю тему, здається, що передача SET ANSI_WARNINGS ON, неявно встановлює ARITHABORT на ON. ЗАРАЗ, якщо SET ARITHABORT OFF також буде передано підключення, навіть якщо ANSI_WARNINGS перекриє його, SQL-сервер все ще буде "діяти", як ARITHABORT ВИМКНЕНО, як при виборі дивних планів. Я знаходжу це ... привабливо. Тож без сумніву, це потрібно встановити підключення І ВИМОЖИТИ АРІТАБОРТ ВИКЛ. Навіть не може існувати. Справа закрита в мене на очах ... sqlservercentral.com/forums/topic/…
Eric Swiggum

@EricSwiggum Цікава тема, яку ти знайшов. Однак я не бачу, як ви робите висновок із цієї інформації, що її потрібно встановити у зв'язку. Якщо нічого в даний час не перекриваючи його, то ми знаємо , що SET ARITHABORT OFFце НЕ присутній. То чому б турбуватися про те, що він присутній? Єдиний екземпляр, який ми бачили, де переорієнтовано за замовчуванням, - це встановлення SSMS ON(це добре). Так чи інакше, я оновив свою відповідь тестуванням і тим, що вважаю найбільш логічною рекомендацією (за наявною інформацією).
Соломон Руцький

1
Я погоджуюся, увімкніть налаштування для екземпляра за замовчуванням. Але в кінцевому підсумку з'єднання контролює те, що встановлено. Як щодо випадку спільних випадків, коли різні технології / протоколи підключаються до SQL? Я маю на увазі, чи потрібно бігати навколо і кричати "НАЛАШТУВАТИ АРІТАБОРТ", щоб розвиватися, як божевільна людина? або, принаймні, сприяти відсутності ARITHABORT OFF, якщо це можливо. Я також вважаю дивним, що до цього часу я не бачив, щоб це прийшло в голову, на моєму шостому курсі DBA. а може, це випадок, коли я не вивчив це досить важко. Назад мені Пол чи Ерланд, LOL, що з цим?
Ерік Свіггум

@EricSwiggum 1) Вам не потрібно буде бігати навколо крику, якщо ви змінили типовий рівень екземпляра. 2) Вам потрібно буде заохочувати відсутність, ARITHABORT OFF якщо ви виявите фактичні випадки його виникнення. Поки, ймовірно, їх немає. 3) Оскільки це впливає на плани запитів, можливо, у таблицях ніколи не було достатньо даних, щоб змусити SQL Server мати певний вибір, де зараз є більше варіантів, а деякі - погані. Або, можливо, є й інші перехідні фактори, такі як застаріла статистика тощо. Не зовсім впевнено.
Соломон Руцький

@EricSwiggum Я з вами там не згоден. Я думаю, що це дуже схоже на те, що я згадував на початку своєї відповіді (тобто порівняння за замовчуванням для американських англійських систем): страх Microsoft перед застарілими системами отримати помилки після оновлення (тобто зворотну гарантію сумісності) приносить більше шкоди, ніж користі, як насправді збільшує встановлення / розмір неідеального сценарію. Це робить все більшим тягнення залишатися в минулому і постійно зменшується шанс покращитись. Це випадки, коли краще зірвати допомогу та просто пережити біль.
Соломон Руцький
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.