Є деякі параметри за замовчуванням, які існують лише тому, що ніхто насправді не знає, який був би ефект від їх зміни. Наприклад, зіставлення рівня екземплярів за замовчуванням при установці в системі, яка використовує "англійська мова США" як мова ОС 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)
Висновок
Враховуючи, що:
- Мабуть, користі від того, щоб мати
ARITHABORT OFF
- Користь матиме
ARITHABORT ON
- Установка з'єднання за замовчуванням (якщо це не перекрито з'єднанням) =
OFF
- Не видається, що або ODBC, або OLEDB / .NET SqlClient намагаються встановити
ARITHABORT
, таким чином вони приймають налаштування за замовчуванням
Я б запропонував змінити параметри підключення за замовчуванням для всіх примірників (як показано вище). Це було б менш нав'язливо, ніж оновлення програми. Я б оновив додаток лише в тому випадку, якщо ви виявите проблему зі зміною налаштування для всіх екземплярів.
PS Я зробив простий тест зі зміною tempdb
та не зміною налаштування на весь екземпляр, і, здається, він не працює.