Existem alguns padrões simplesmente porque ninguém sabe realmente qual seria o efeito de alterá-los. Por exemplo, o agrupamento padrão no nível da instância ao instalar em um sistema que usa "inglês dos EUA" como o idioma do sistema operacional SQL_Latin1_General_CP1_CI_AS
. Isso não faz sentido, pois os SQL_*
agrupamentos são para compatibilidade anterior ao SQL Server 2000. A partir do SQL Server 2000, era possível escolher um agrupamento do Windows e, portanto, o padrão para sistemas em inglês dos EUA deveria ter sido alterado para Latin1_General_CI_AS
. MAS, acho que ninguém na Microsoft sabe realmente qual será o impacto para todos os vários subsistemas potenciais e procedimentos armazenados do sistema etc.
Portanto, não conheço nenhum impacto negativo específico de configurá-lo como LIGADO como um padrão de banco de dados ou mesmo para toda a instância. Ao mesmo tempo, eu não testei. Mas, mesmo que eu o tenha testado, talvez ainda não use os mesmos caminhos de código que seu aplicativo, portanto, isso é algo que você realmente precisa testar em seu ambiente. Defina comoON
no nível da instância em seus ambientes Dev e QA e veja como isso funciona por um mês ou dois. Em seguida, ative-o no armazenamento temporário / UAT. Se tudo continuar funcionando por várias semanas, role essa alteração de configuração para Produção. A chave é conceder o máximo de tempo possível para testar vários caminhos de código que não são atingidos diariamente. Alguns são atingidos semanalmente ou meses ou anualmente. Alguns caminhos de código são atingidos apenas pelo suporte ou por algum relatório ad hoc ou processo de manutenção que alguém criou anos atrás e nunca lhe contou e só é usado em intervalos aleatórios (nah, isso nunca acontece ;-).
Portanto, fiz alguns testes em uma instância que ainda possui a configuração "opções do usuário" padrão, pois nunca a alterei.
Observe:
@@OPTIONS
/ 'user options'
é um valor mascarado
- 64 é o bit para
ARITHABORT ON
CONFIGURAÇÃO
Testei com o SQLCMD (que usa ODBC) e o LINQPad (que usa o .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 .
(o ^
é o caractere de continuação de linha do DOS; o .
da última linha é apenas para forçar a linha extra para facilitar a copiar e colar)
No 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());
}
}
TESTE 1: Antes
SQLCMD retorna:
master: 0 (ODBC)
O LINQPad retorna:
tempdb: 0 (.Net SqlClient Data Provider)
MUDAR A OPÇÃO DE CONEXÃO PADRÃO:
O T-SQL a seguir é ativado ARITHABORT
sem remover nenhuma outra opção que possa ser definida e sem alterar nada, se ARITHABORT
já estiver definido no valor de máscara de 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;
TESTE 2: Depois
SQLCMD retorna:
master: 64 (ODBC)
O LINQPad retorna:
tempdb: 64 (.Net SqlClient Data Provider)
Conclusão
Dado que:
- Não parece haver nenhum benefício em ter
ARITHABORT OFF
- Há benefício em ter
ARITHABORT ON
- A configuração de conexão padrão (a menos que substituída pela conexão) =
OFF
- Não parece que o ODBC ou OLEDB / .NET SqlClient tente definir
ARITHABORT
, portanto eles aceitam a configuração padrão
Eu sugeriria alterar as opções de conexão padrão para toda a instância (como mostrado acima). Isso seria menos invasivo do que atualizar o aplicativo. Eu atualizaria o aplicativo apenas se você encontrar um problema ao alterar a configuração de toda a instância.
PS: Fiz um teste simples alterando tempdb
e não alterando a configuração de toda a instância e ela não pareceu funcionar.