Es gibt einige Standardeinstellungen, nur weil niemand wirklich weiß, wie sich eine Änderung auswirken würde. Beispiel: Die Standardkollation auf Instanzebene bei der Installation auf einem System, das "US-Englisch" als Betriebssystemsprache verwendet SQL_Latin1_General_CP1_CI_AS. Dies ist nicht sinnvoll, da die SQL_*Sortierungen aus Gründen der Kompatibilität vor SQL Server 2000 dienen. Ab SQL Server 2000 Sie könnten eine Windows - Sortierung tatsächlich wählen und so den Standard für US - Englisch Systeme sollten geändert wurden Latin1_General_CI_AS. ABER ich denke, niemand bei Microsoft weiß wirklich, welche Auswirkungen dies auf die verschiedenen potenziellen Subsysteme und gespeicherten Systemprozeduren usw. haben wird.
Daher sind mir keine spezifischen negativen Auswirkungen der Einstellung auf ON als Datenbankstandard oder sogar instanzweit bekannt. Gleichzeitig habe ich es nicht getestet. Aber selbst wenn ich es getestet hätte, würde ich möglicherweise nicht dieselben Codepfade wie Ihre Anwendung verwenden. Dies ist also etwas, das Sie wirklich in Ihrer Umgebung testen müssen. Stellen Sie es aufONauf Instanzebene in Ihren Entwicklungs- und QS-Umgebungen und sehen Sie, wie das für ein oder zwei Monate funktioniert. Aktivieren Sie es dann in Staging / UAT. Wenn mehrere Wochen lang alles gut läuft, ändern Sie diese Konfigurationsänderung in Produktion. Der Schlüssel besteht darin, so viel Zeit wie möglich für das Testen verschiedener Codepfade zu geben, die nicht täglich aufgerufen werden. Einige werden wöchentlich oder monatelang oder jährlich getroffen. Einige Codepfade werden nur vom Support oder von einem Ad-hoc-Bericht oder Wartungsprozess getroffen, den jemand vor Jahren erstellt hat und der Ihnen nie davon erzählt hat und der nur in zufälligen Abständen verwendet wird (nein, das passiert nie ;-).
Daher habe ich einige Tests an einer Instanz durchgeführt, die immer noch die Standardeinstellung "Benutzeroptionen" hat, da ich sie nie geändert habe.
Bitte beachten Sie:
@@OPTIONS/ 'user options'ist ein bitmaskender Wert- 64 ist das Bit für
ARITHABORT ON
INSTALLIEREN
Ich habe sowohl mit SQLCMD (das ODBC verwendet) als auch mit LINQPad (das .NET SqlClient verwendet) getestet:
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 .
(Dies ^ist das DOS-Zeilenfortsetzungszeichen. Das .in der letzten Zeile dient nur dazu, die zusätzliche Zeile zu erzwingen, um das Kopieren und Einfügen zu vereinfachen.)
In 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: Vorher
SQLCMD gibt zurück:
master: 0 (ODBC)
LINQPad gibt Folgendes zurück:
tempdb: 0 (.Net SqlClient Data Provider)
STANDARDVERBINDUNGSOPTION ÄNDERN:
Das folgende T-SQL wird aktiviert, ARITHABORTohne dass andere Optionen entfernt werden, die möglicherweise festgelegt wurden, und ohne dass etwas ARITHABORTgeändert wird , wenn dies bereits im bitmaskenen Wert festgelegt ist.
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: Nachher
SQLCMD gibt zurück:
master: 64 (ODBC)
LINQPad gibt Folgendes zurück:
tempdb: 64 (.Net SqlClient Data Provider)
Fazit
Vorausgesetzt, dass:
- Es scheint keinen Vorteil zu haben
ARITHABORT OFF
- Es hat Vorteile zu haben
ARITHABORT ON
- Die Standardverbindungseinstellung (sofern nicht durch die Verbindung überschrieben) =
OFF
- Es scheint nicht, dass ODBC oder OLEDB / .NET SqlClient versuchen, eine Einstellung vorzunehmen
ARITHABORT, daher akzeptieren sie die Standardeinstellung
Ich würde vorschlagen, die instanzweiten Standardverbindungsoptionen zu ändern (wie oben gezeigt). Dies wäre weniger aufdringlich als das Aktualisieren der Anwendung. Ich würde die App nur aktualisieren, wenn Sie ein Problem beim Ändern der instanzweiten Einstellung finden.
PS Ich habe einen einfachen Test durchgeführt, bei dem die instanzweite Einstellung geändert tempdbund nicht geändert wurde, und es schien nicht zu funktionieren.