Есть некоторые значения по умолчанию, которые существуют только потому, что никто не знает, каков будет результат их изменения. Например, сопоставление по умолчанию на уровне экземпляра при установке в системе, в которой в качестве языка операционной системы используется «американский английский» SQL_Latin1_General_CP1_CI_AS
. Это не имеет смысла, поскольку параметры SQL_*
сортировки предназначены для совместимости до SQL Server 2000. Начиная с SQL Server 2000, вы на самом деле можете выбирать параметры сортировки Windows, поэтому значение по умолчанию для систем на английском языке США должно быть изменено на Latin1_General_CI_AS
. НО, я думаю, никто в Microsoft не знает, как это повлияет на все возможные подсистемы, системные хранимые процедуры и т. Д.
Таким образом, я не знаю о каком-либо конкретном негативном влиянии установки его в значение ON как базы данных по умолчанию или даже для всего экземпляра. В то же время я не проверял это. Но даже если бы я его протестировал, я бы все равно не использовал те же пути кода, что и ваше приложение, так что это то, что вам действительно нужно протестировать в вашей среде. Установите этоON
на уровне экземпляра в ваших средах разработки и тестирования и посмотрите, как это работает в течение месяца или двух. Затем включите его в 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
а не с изменением настроек для всего экземпляра, и, похоже, это не сработало.