Início / dba / Perguntas / 237860
Accepted
Eric Swiggum
Asked: 2019-05-11 09:08:23 +0800 CST

Quais são as ramificações de definir ARITHABORT ON para todas as conexões no SQL Server?

  • 772

Portanto, determinei que o comportamento errático do meu SQL Server é devido à configuração padrão do .Net SqlClient Data Provider de SET ARITHABORT OFF. Com isso dito, li vários artigos que debatem a melhor maneira de implementar isso. Para mim, eu só quero uma maneira fácil porque o SQL Server está sofrendo e meu ajuste de consulta não transcendeu totalmente o aplicativo (e, obviamente, adicionar o SETem um sp NÃO FUNCIONA).

No brilhante artigo de Erland Sommarskog sobre o assunto, ele basicamente sugere adotar a abordagem segura alterando o aplicativo para emitir SET ARITHABORT ONpara a conexão. No entanto, nesta resposta de uma pergunta dba.stackexchange , Solomon Rutzky oferece uma abordagem em toda a instância e em todo o banco de dados.

Quais ramificações estou perdendo aqui com a configuração dessa instância? Como eu vejo ... como o SSMS tem isso definido ONpor padrão, não vejo nenhum mal em definir isso ONem todo o servidor para todas as conexões. No final das contas, só preciso que esse SQL Server funcione acima de tudo.

sql-server performance

1 respostas

  1. Best Answer

    Existem alguns padrões que existem simplesmente porque ninguém sabe realmente qual seria o efeito de alterá-los. Por exemplo, o agrupamento de nível de instância padrão ao instalar em um sistema que usa "inglês dos EUA" como 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, você pode escolher um agrupamento do Windows e, portanto, o padrão para sistemas em inglês dos EUA deve ter sido alterado para Latin1_General_CI_AS. MAS, acho que ninguém na Microsoft sabe realmente qual será o impacto em todos os vários subsistemas potenciais e procedimentos armazenados do sistema, etc.

    Portanto, não estou ciente de nenhum impacto negativo específico de defini-lo como ON como um padrão de banco de dados ou mesmo em toda a instância. Ao mesmo tempo, não testei. Mas mesmo se eu tivesse testado, ainda posso não usar os mesmos caminhos de código que seu aplicativo, então isso é algo que você realmente precisa testar em seu ambiente. Defina paraONno nível da instância em seus ambientes de desenvolvimento e controle de qualidade e veja como isso funciona por um mês ou dois. Em seguida, habilite-o em Staging / UAT. Se tudo continuar indo bem por várias semanas, passe essa alteração de configuração para Produção. A chave é dar 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 algum relatório ad hoc ou proc 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 ;-).

    Então, fiz alguns testes em uma instância que ainda tem a configuração padrão de "opções do usuário", pois nunca a alterei.

    Observe:

    • @@OPTIONS/ 'user options'é um valor com máscara de bits
    • 64 é o bit paraARITHABORT ON

    CONFIGURAR

    Testei com SQLCMD (que usa ODBC) e LINQPad (que usa .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 da linha do DOS; o .da última linha é apenas para forçar a linha extra para facilitar a cópia e colagem)

    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)

    ALTERAR OPÇÃO DE CONEXÃO PADRÃO:

    O T-SQL a seguir habilita ARITHABORTsem remover nenhuma outra opção que possa ser definida e sem alterar nada se ARITHABORTjá estiver definido no valor de máscara de bits.

    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:

    1. Não parece haver nenhum benefício em terARITHABORT OFF
    2. Há vantagem em terARITHABORT ON
    3. A configuração de conexão padrão (a menos que substituída pela conexão) =OFF
    4. Não parece que o ODBC ou OLEDB / .NET SqlClient tente definir ARITHABORT, portanto, eles aceitam a configuração padrão

    Sugiro alterar as opções de conexão padrão em toda a instância (como mostrado acima). Isso seria menos intrusivo do que atualizar o aplicativo. Eu só atualizaria o aplicativo se você encontrar um problema ao alterar a configuração de toda a instância.

    PS Eu fiz um teste simples com alteração tempdbe não alteração da configuração de toda a instância e não pareceu funcionar.

    • 11

relate perguntas