Quali sono le conseguenze dell'impostazione di ARITHABORT su tutte le connessioni in SQL Server?

Quindi ho determinato che il comportamento irregolare del mio SQL Server è dovuto all'impostazione predefinita di .Net SqlClient Data Provider SET ARITHABORT OFF. Detto questo, ho letto vari articoli che discutono il modo migliore per implementarlo. Per me, voglio solo un modo semplice perché SQL Server sta soffrendo e la mia ottimizzazione delle query non è stata completamente trascesa attraverso l'app (e ovviamente aggiungendo il comando SETin un sp NON FUNZIONA).

Nel brillante articolo di Erland Sommarskog sull'argomento, in sostanza suggerisce di adottare un approccio sicuro alterando l'app da emettere SET ARITHABORT ONper la connessione. Tuttavia, in questa risposta da una domanda dba.stackexchange , Solomon Rutzky offre un approccio sia a livello di istanza che a livello di database.

Quali ramificazioni mi sto perdendo qui con l'impostazione di questa istanza a livello? Per come la vedo io ... dato che SSMS ha questo set ONdi default, non vedo alcun danno nell'impostare questo ONserver per tutte le connessioni. Alla fine, ho solo bisogno che questo SQL Server funzioni al di sopra di tutto.

Ci sono alcune impostazioni predefinite che esistono semplicemente perché nessuno sa davvero quale sarebbe l'effetto di cambiarle. Ad esempio, il confronto a livello di istanza predefinito durante l'installazione su un sistema che utilizza "inglese americano" come lingua del sistema operativo è SQL_Latin1_General_CP1_CI_AS. Ciò non ha senso poiché le SQL_*regole di confronto sono compatibili con SQL Server 2000. A partire da SQL Server 2000 si potrebbe effettivamente scegliere un confronto di Windows, quindi l'impostazione predefinita per i sistemi inglesi statunitensi avrebbe dovuto essere modificata Latin1_General_CI_AS. MA, suppongo che nessuno in Microsoft sappia davvero quale sarà l'impatto su tutti i vari sottosistemi potenziali e sulle procedure memorizzate di sistema, ecc.

Quindi, non sono a conoscenza di alcun impatto negativo specifico dell'impostazione su ON come predefinito del database o anche a livello di istanza. Allo stesso tempo, non l'ho provato. Ma anche se lo avessi testato, potrei ancora non utilizzare gli stessi percorsi di codice della tua applicazione, quindi questo è qualcosa che devi davvero testare nel tuo ambiente. Impostalo suONa livello di istanza nei tuoi ambienti Dev e QA e scopri come funziona per un mese o due. Quindi abilitalo in Staging / UAT. Se tutto continua a funzionare bene per diverse settimane, ruota la configurazione in Modifica. La chiave è dedicare più tempo possibile al test di vari percorsi di codice che non vengono raggiunti quotidianamente. Alcuni vengono colpiti settimanalmente o mesi o annualmente. Alcuni percorsi di codice sono colpiti solo dal supporto o da un rapporto ad hoc o da un proc di manutenzione che qualcuno ha creato anni fa e di cui non ti ha mai parlato e che viene utilizzato solo a intervalli casuali (nah, ciò non accade mai ;-).

Quindi, ho fatto alcuni test su un'istanza che ha ancora l'impostazione predefinita "opzioni utente" in quanto non l'ho mai cambiata.

Notare che:

• @@OPTIONS/ 'user options'è un valore con maschera di bit
• 64 è il bit per ARITHABORT ON

IMPOSTARE

Ho testato sia con SQLCMD (che utilizza ODBC) sia LINQPad (che utilizza .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 .

^{( ^è il carattere di continuazione della riga DOS; l' .ultima riga serve solo a forzare la riga aggiuntiva per facilitare il copia e incolla)}

Nel 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: Prima

Restituisce SQLCMD:

master: 0 (ODBC)

Restituisce LINQPad:

tempdb: 0 (.Net SqlClient Data Provider)

MODIFICA OPZIONE DI CONNESSIONE PREDEFINITA:

Il seguente T-SQL abilita ARITHABORTsenza rimuovere altre opzioni che potrebbero essere impostate e senza modificare nulla se ARITHABORTè già impostato nel valore con maschera di bit.

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: Dopo

Restituisce SQLCMD:

master: 64 (ODBC)

Restituisce LINQPad:

tempdb: 64 (.Net SqlClient Data Provider)

Conclusione

Dato che:

1. Non sembra esserci alcun vantaggio nell'avere ARITHABORT OFF
2. C'è un vantaggio nell'avere ARITHABORT ON
3. L'impostazione di connessione predefinita (a meno che non venga ignorata dalla connessione) = OFF
4. Non sembra che ODBC o OLEDB / .NET SqlClient tentino di impostare ARITHABORT, quindi accettano l'impostazione predefinita

Suggerirei di modificare le opzioni di connessione predefinite a livello di istanza (come mostrato sopra). Questo sarebbe meno invadente rispetto all'aggiornamento dell'applicazione. Vorrei aggiornare l'app solo se riscontri un problema con la modifica delle impostazioni a livello di istanza.

PS Ho fatto un semplice test cambiando tempdbe non cambiando l'impostazione a livello di istanza e non sembrava funzionare.