Istnieją pewne domyślne ustawienia, ponieważ nikt tak naprawdę nie wie, jaki byłby skutek ich zmiany. Na przykład domyślne sortowanie na poziomie instancji podczas instalacji w systemie, który używa języka „US English” jako języka systemu operacyjnego SQL_Latin1_General_CP1_CI_AS. Nie ma to sensu, ponieważ SQL_*zestawienia dotyczą zgodności z wersją wcześniejszą niż SQL Server 2000. Począwszy od SQL Server 2000 można właściwie wybrać sortowanie w systemie Windows, dlatego domyślne ustawienie dla systemów w języku angielskim w USA powinno zostać zmienione na Latin1_General_CI_AS. ALE, myślę, że nikt w Microsoft naprawdę nie wie, jaki będzie wpływ na wszystkie potencjalne podsystemy i procedury przechowywane w systemie itp.
Tak więc nie jestem świadomy żadnego konkretnego negatywnego wpływu ustawienia go na ON jako domyślną bazę danych lub nawet na całą instancję. Jednocześnie go nie testowałem. Ale nawet gdybym go przetestował, nadal mogę nie używać tych samych ścieżek kodu co Twoja aplikacja, więc jest to coś, co naprawdę musisz przetestować w swoim środowisku. Ustaw naONna poziomie instancji w środowiskach deweloperów i kontroli jakości i zobacz, jak to działa przez miesiąc lub dwa. Następnie włącz to w Staging / UAT. Jeśli wszystko pójdzie dobrze przez kilka tygodni, przenieś tę zmianę konfiguracji do Produkcji. Kluczem jest poświęcenie jak największej ilości czasu na przetestowanie różnych ścieżek kodu, które nie są trafiane codziennie. Niektóre trafiają co tydzień lub miesiące lub co roku. Niektóre ścieżki kodu są dotknięte jedynie wsparciem lub raportem ad hoc lub procesem konserwacji, o którym ktoś utworzył lata temu i o którym nigdy nie mówił, i przyzwyczaja się tylko w przypadkowych odstępach czasu (nie, to się nigdy nie zdarza ;-).
Przeprowadziłem więc testy na instancji, która wciąż ma domyślne ustawienie „opcji użytkownika”, ponieważ nigdy go nie zmieniłem.
Proszę zanotować:
@@OPTIONS/ 'user options'jest wartością maski bitowej- 64 to bit
ARITHABORT ON
USTAWIAĆ
Testowałem zarówno z SQLCMD (który używa ODBC), jak i LINQPad (który używa .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 .
( ^jest to znak kontynuacji linii DOS; w .ostatnim wierszu jest tylko wymuszenie dodatkowej linii, aby ułatwić kopiowanie i wklejanie)
W 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());
}
}
TEST 1: Przedtem
SQLCMD zwraca:
master: 0 (ODBC)
LINQPad zwraca:
tempdb: 0 (.Net SqlClient Data Provider)
ZMIEŃ DOMYŚLNĄ OPCJĘ POŁĄCZENIA:
Poniższy T-SQL włącza ARITHABORTbez usuwania innych opcji, które mogą być ustawione, i bez zmiany czegokolwiek, jeśli ARITHABORTjest już ustawiony w wartości maski bitowej.
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;
TEST 2: Po
SQLCMD zwraca:
master: 64 (ODBC)
LINQPad zwraca:
tempdb: 64 (.Net SqlClient Data Provider)
Wniosek
Jeśli się uwzględni:
- Wydaje się, że nie ma z tego żadnej korzyści
ARITHABORT OFF
- Ma to korzyść
ARITHABORT ON
- Domyślne ustawienie połączenia (chyba że zostanie zastąpione przez połączenie) =
OFF
- Nie wydaje się, aby próbowała ustawić ODBC lub OLEDB / .NET SqlClient
ARITHABORT, dlatego akceptują ustawienie domyślne
Sugerowałbym zmianę domyślnych opcji połączenia dla całej instancji (jak pokazano powyżej). Byłoby to mniej nachalne niż aktualizowanie aplikacji. Zaktualizowałbym aplikację tylko wtedy , gdy znajdziesz problem ze zmianą ustawień dla całej instancji.
PS Zrobiłem prosty test, zmieniając tempdbi nie zmieniając ustawienia dla całej instancji i nie działało.